Mailing List Archive

maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
> > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
> > Here's my suggestion, for what it's worth :)
> >
> > The layout on disk and the semantics of categories do not need to be related.
> Yes and no. You're assuming that people don't use the layout on disk for digging
> around without calling portage. Personally, I do.
>
> > I like the idea of using the first character of a package name as the
> > sub-directory name. This can be extended more deeply as and when necessary to
> > avoid over-large directories which cause problems on some filesystems. e.g.
> > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is
> > architecture-neutral, rsyncable, scalable, and not too difficult for users to
> > parse manually (see later for searching through categories). If the algorithm
> > portage would use to locate a package is such that it doesn't mandate the depth
> > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/"
> > exists) then overlays can have a different depth to the rsync tree; if you only
> > have a few packages in overlay then they need not be in subdirectories at all.
> Re-asserting that the fs layout *does* matter, how is that more intuitive when trying
> to track down the ebuild for dev-util/diffball ?


The fact that the directory where diffball is is easily deducable by its
name. As it is, I'd be a bit lost if I had to guess whether diffball is
in app-arch or dev-util. Even if I remembered it was something
dev-related I'd still be inclined to look in sys-devel.

As it is, for those who don't use a given package on an everyday basis
the categories are extremely obscure.

> How many directories deep would I have to go before I reached the
> ebuild?

Does it matter? You know the path exactly. It's p/portage. It's
not ... "was it sys-apps/portage or app-portage/portage"?

... skip a bit ...

> > Having said that, some things could be done now. If a flat package namespace
> > is desirable, the existing package name clashes could be resolved by renaming
> > the few packages that clash.
> 74 packages, roughly, out of 9429 roughly.

76/9295, which is not that bad, considering about half of them are
emacs/xemacs related.

> > Category could be added as a field in
> > metadata.xml, so that a package could "belong" to multiple categories.
> > The query/search tools could be enhanced to scan this metadata (perhaps including
> > the current category directory as an implied entry in the metadata.xml).
> If that's the goal of the "belong to N categories" thread, strictly searching,
> sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv
> nonconflicting bit.

I personally want to see the category part *disappear* from the *DEPEND
which is one of the reasons to advocate a flat tree. If the category (or
part of it) goes in the package name, so be it, but at least there will
be no package moves to break older ebuilds or outdated overlays.

--
\ Georgi Georgiev \ Taxes, n.: Of life's two certainties, the \
/ chutz@gg3.net / only one for which you can get an extension. /
\ +81(90)2877-8845 \ \
--
gentoo-dev@gentoo.org mailing list

On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote:
> maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
> > > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
> > > Here's my suggestion, for what it's worth :)
> > >
> > > The layout on disk and the semantics of categories do not need to be related.
> > Yes and no. You're assuming that people don't use the layout on disk for digging
> > around without calling portage. Personally, I do.
> >
> > > I like the idea of using the first character of a package name as the
> > > sub-directory name. This can be extended more deeply as and when necessary to
> > > avoid over-large directories which cause problems on some filesystems. e.g.
> > > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is
> > > architecture-neutral, rsyncable, scalable, and not too difficult for users to
> > > parse manually (see later for searching through categories). If the algorithm
> > > portage would use to locate a package is such that it doesn't mandate the depth
> > > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/"
> > > exists) then overlays can have a different depth to the rsync tree; if you only
> > > have a few packages in overlay then they need not be in subdirectories at all.
> > Re-asserting that the fs layout *does* matter, how is that more intuitive when trying
> > to track down the ebuild for dev-util/diffball ?
>
>
> The fact that the directory where diffball is is easily deducable by its
> name. As it is, I'd be a bit lost if I had to guess whether diffball is
> in app-arch or dev-util. Even if I remembered it was something
> dev-related I'd still be inclined to look in sys-devel.
dev-util is accurate (it's a compressor, but a specialized variant,
same as patch is). From it's current fs location/layout, we get thus-
quick lookup on the atom, and inference of it's intentions. This is
why we have xml at the category level, for example.

One thing that's being unstated also- it's implicitly stated that this
directory structure is somehow easier to look up a package. If you
know the _exact_ package name, maybe. Otherwise, you're falling back
to a search tool (which defeats to some degree the whole arguement for
flattened namespace).
Some quicky python, grouping by first char of the package name, and
you wind up with (top 8)-
421, 521, 571, 582, 657, 663, 664, 746
Seperate directories within an individual directory. Say 'd' for
example, and we'll pretend 746 is the count of packages that start
with 'd'. That's a butload of directories to go digging in.

The response would be, "well then extend it to the first two chars
after the first dir". You narrow it down, but add another layer of
dirs, again, for what gain?

See, the thing I find odd about this thread/request is that
essentially breaking it down to first letter groupping, is being
argued as being _easier_ for people, while allowing multi cats, or
just flat out dropping the category aspect. The example above, imo,
proves otherwise.

Keep in mind at this point, the discussion is whats easiest for
_humans_. What's easiest for code/comp is another matter, and (within
limits) can work with anything that's thrown at it.

> > How many directories deep would I have to go before I reached the
> > ebuild?
>
> Does it matter? You know the path exactly. It's p/portage. It's
> not ... "was it sys-apps/portage or app-portage/portage"?
I know the path as sys-apps/portage already though. Doesn't that
count for something? :)

Or, a bit more likely case, I know the type of the package, the
category, but don't recall it's exact name. What y'all are proposing
forces the user to use a tool, rather then just a quicky ls.

> > > Having said that, some things could be done now. If a flat package namespace
> > > is desirable, the existing package name clashes could be resolved by renaming
> > > the few packages that clash.
> > 74 packages, roughly, out of 9429 roughly.
>
> 76/9295, which is not that bad, considering about half of them are
> emacs/xemacs related.
'cept either you, or someone else was proposing a totally flat
namespace, no cats in the atoms. That means the count of changes (the
76 above is just # of conflicting packages) is around 19000, plus a
fairly large amount of portage modifications.

> > > Category could be added as a field in
> > > metadata.xml, so that a package could "belong" to multiple categories.
> > > The query/search tools could be enhanced to scan this metadata (perhaps including
> > > the current category directory as an implied entry in the metadata.xml).
> > If that's the goal of the "belong to N categories" thread, strictly searching,
> > sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv
> > nonconflicting bit.
>
> I personally want to see the category part *disappear* from the *DEPEND
> which is one of the reasons to advocate a flat tree. If the category (or
> part of it) goes in the package name, so be it, but at least there will
> be no package moves to break older ebuilds or outdated overlays.
Frankly, you need to give a *really* damn good reason for why this is
better. I don't think it is, convince me otherwise.

What do we gain from a flat namespace?
Right now, I can infer an atom out of a DEPEND string's purpose to
some degree, based upon it's category. To head off the "well you
don't need to know the category, you should know the packages
intentions if you're modifying the ebuild", that dodges the point; via
the category portion of an atom, I can infer at least -intention- of a
package.

Ignoring changes required (have stated them already, no point in
sniping ya over it), what _exactly_ do we gain from the change?
~brian
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
> On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote:
>
>>maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
>>
>>>>On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
>>>>Here's my suggestion, for what it's worth :)
>>>>
>>>>The layout on disk and the semantics of categories do not need to be related.
>>>
>>>Yes and no. You're assuming that people don't use the layout on disk for digging
>>>around without calling portage. Personally, I do.
Not need to be related, but shouldn't be related. In essence this
allows people to put the tree where-ever, as long as that storage
mechanism supports the database operations required ( stuffing
everything in a SQL db fex ). I don't know why someone would....but hey ;)
>>>
>>>
>>>>I like the idea of using the first character of a package name as the
>>>>sub-directory name. This can be extended more deeply as and when necessary to
>>>>avoid over-large directories which cause problems on some filesystems. e.g.
>>>>for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is
>>>>architecture-neutral, rsyncable, scalable, and not too difficult for users to
>>>>parse manually (see later for searching through categories). If the algorithm
>>>>portage would use to locate a package is such that it doesn't mandate the depth
>>>>(i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/"
>>>>exists) then overlays can have a different depth to the rsync tree; if you only
>>>>have a few packages in overlay then they need not be in subdirectories at all.
>>>
>>>Re-asserting that the fs layout *does* matter, how is that more intuitive when trying
>>>to track down the ebuild for dev-util/diffball ?
>>
>>
>>The fact that the directory where diffball is is easily deducable by its
>>name. As it is, I'd be a bit lost if I had to guess whether diffball is
>>in app-arch or dev-util. Even if I remembered it was something
>>dev-related I'd still be inclined to look in sys-devel.
>
> dev-util is accurate (it's a compressor, but a specialized variant,
> same as patch is). From it's current fs location/layout, we get thus-
> quick lookup on the atom, and inference of it's intentions. This is
> why we have xml at the category level, for example.
>
> One thing that's being unstated also- it's implicitly stated that this
> directory structure is somehow easier to look up a package. If you
> know the _exact_ package name, maybe. Otherwise, you're falling back
> to a search tool (which defeats to some degree the whole arguement for
> flattened namespace).
> Some quicky python, grouping by first char of the package name, and
> you wind up with (top 8)-
> 421, 521, 571, 582, 657, 663, 664, 746
Assuming the directories are ordered by letter, ( a,b,c,d ) and
subdirectories if present as well, a bsearch wouldn't be bad. Both are
ordered sets and you can quickly determine the location of a package in
log(n) time. I don't see a big deal here.
> Seperate directories within an individual directory. Say 'd' for
> example, and we'll pretend 746 is the count of packages that start
> with 'd'. That's a butload of directories to go digging in.
>
> The response would be, "well then extend it to the first two chars
> after the first dir". You narrow it down, but add another layer of
> dirs, again, for what gain?
>
> See, the thing I find odd about this thread/request is that
> essentially breaking it down to first letter groupping, is being
> argued as being _easier_ for people, while allowing multi cats, or
> just flat out dropping the category aspect. The example above, imo,
> proves otherwise.
>
> Keep in mind at this point, the discussion is whats easiest for
> _humans_. What's easiest for code/comp is another matter, and (within
> limits) can work with anything that's thrown at it.
>
>
>>>How many directories deep would I have to go before I reached the
>>>ebuild?
>>
>>Does it matter? You know the path exactly. It's p/portage. It's
>>not ... "was it sys-apps/portage or app-portage/portage"?
>
> I know the path as sys-apps/portage already though. Doesn't that
> count for something? :)
>
> Or, a bit more likely case, I know the type of the package, the
> category, but don't recall it's exact name. What y'all are proposing
> forces the user to use a tool, rather then just a quicky ls.

*tongue in cheek* and what is ls but another tool for listing the
contents of a directory :)

>>>>Having said that, some things could be done now. If a flat package namespace
>>>>is desirable, the existing package name clashes could be resolved by renaming
>>>>the few packages that clash.
>>>
>>>74 packages, roughly, out of 9429 roughly.
>>
>>76/9295, which is not that bad, considering about half of them are
>>emacs/xemacs related.
>
> 'cept either you, or someone else was proposing a totally flat
> namespace, no cats in the atoms. That means the count of changes (the
> 76 above is just # of conflicting packages) is around 19000, plus a
> fairly large amount of portage modifications.
>
>
>>>> Category could be added as a field in
>>>>metadata.xml, so that a package could "belong" to multiple categories.
>>>> The query/search tools could be enhanced to scan this metadata (perhaps including
>>>>the current category directory as an implied entry in the metadata.xml).
>>>
>>>If that's the goal of the "belong to N categories" thread, strictly searching,
>>>sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv
>>>nonconflicting bit.
>>
>>I personally want to see the category part *disappear* from the *DEPEND
>>which is one of the reasons to advocate a flat tree. If the category (or
>>part of it) goes in the package name, so be it, but at least there will
>>be no package moves to break older ebuilds or outdated overlays.
>
> Frankly, you need to give a *really* damn good reason for why this is
> better. I don't think it is, convince me otherwise.
>
> What do we gain from a flat namespace?
> Right now, I can infer an atom out of a DEPEND string's purpose to
> some degree, based upon it's category. To head off the "well you
> don't need to know the category, you should know the packages
> intentions if you're modifying the ebuild", that dodges the point; via
> the category portion of an atom, I can infer at least -intention- of a
> package.

The CPV thing.....is a big fix :(

> Ignoring changes required (have stated them already, no point in
> sniping ya over it), what _exactly_ do we gain from the change?
> ~brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoIghmzglR5RwbyYAQJa4w//WOTxQGm59JK96uX2MlLTlIG9kjFRhKTk
AJjPybvOrJEngUuqhCogzxtsz0FXOX096bUyBO0CZb0mfN7hwW4jZIMDHycYD/kI
AW22E/SrlH4iHi/UrQNzOm2kT6hgg1Vnnt/PqU/W1CqWF3xs8hFOYui61FW9U1WO
Wq5vfxPZQd3cjRT1JQbIX3KJtmzYq8tnfWEaUo9kkSMlIWViFlvH0chEi7s61Na/
W/jfmscHBfx2y2pkITaRHO+JO3DgG412YKmfRe0JuOmcjGLwnrChQZqgSpTaE8e6
6d+ocqtTdAnJc52CbGCNN5RLnkmmYsOFGBtDEc4JKmYoRZZeWszI9QE6Dt+0i+mm
rZAMtVvdRHE3A72cKF+4UiqvhIO2hAdzRE4i4m0h5WAsKrMDXIobeGunROHGCCyu
ctsgH24OcTxX1D0syiQcvB+lvSyxDb2JBnd4gMSDpwEEQrZ9YxLkEVN830XZ6kaV
FLxUj4zyl67iejabfNNBmTymV1i84z3BMeXKayrVp77NUF0swCOC6rlciCFfoSLQ
N5vyFjwEcMsUWnSO2cq5laNDRqIjlw/YfO0Hiy55TCFi/vm5sH44rehntMyq1b3h
xcLJhq7MIPmkfO2qZSZfD8ouB621bAlh4Vc+x+7kyLFaFRdAIQHYIY3rB3DFR5k9
ETcl3w/XVq8=
=SN4n
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Wed, May 11, 2005 at 11:11:02AM -0400, Alec Warner wrote:
> >>>Yes and no. You're assuming that people don't use the layout on disk for digging
> >>>around without calling portage. Personally, I do.
> Not need to be related, but shouldn't be related. In essence this
> allows people to put the tree where-ever, as long as that storage
> mechanism supports the database operations required ( stuffing
> everything in a SQL db fex ). I don't know why someone would....but hey ;)

Not a valid arguement for dropping categories however, since I'm
playing with sqlite based repository module atm locally :)
(don't ask for it, it's not even remotely ready for any use beyond
destroying things locally on my box at the moment)

Category is just a bit of info used for looking up a node (category="xyz"
and package="abc"). Shouldn't isn't applicable here; in this case,
category *is* required due to our atoms, unless people manage to push
flattening the namespace through. :)


> >>The fact that the directory where diffball is is easily deducable by its
> >>name. As it is, I'd be a bit lost if I had to guess whether diffball is
> >>in app-arch or dev-util. Even if I remembered it was something
> >>dev-related I'd still be inclined to look in sys-devel.
> >
> > dev-util is accurate (it's a compressor, but a specialized variant,
> > same as patch is). From it's current fs location/layout, we get thus-
> > quick lookup on the atom, and inference of it's intentions. This is
> > why we have xml at the category level, for example.
> >
> > One thing that's being unstated also- it's implicitly stated that this
> > directory structure is somehow easier to look up a package. If you
> > know the _exact_ package name, maybe. Otherwise, you're falling back
> > to a search tool (which defeats to some degree the whole arguement for
> > flattened namespace).
> > Some quicky python, grouping by first char of the package name, and
> > you wind up with (top 8)-
> > 421, 521, 571, 582, 657, 663, 664, 746
> Assuming the directories are ordered by letter, ( a,b,c,d ) and
> subdirectories if present as well, a bsearch wouldn't be bad. Both are
> ordered sets and you can quickly determine the location of a package in
> log(n) time. I don't see a big deal here.

Dodging my point though. I was pointing out that the categories
approach decreases the number of directories/packages within each
grouping, while first letter approach jacks up the # of dirs w/in dirs
(in some cases, of course). basically, a category fs layout is easier
on the human who is digging in if they don't know what they're exactly
hunting for, point still stands. :)

Regarding bsearch, ehh. listdir returns a list (not an iterable over
the (open|read|close)dir syscall), so you'd have to either resort to a
linear search, or sort then bsearch it. Like I said, the issue isn't
how we code things to make it speedy, my concern outlined above is
purely the human factor in dealing with the proposed tree
structure.


> > I know the path as sys-apps/portage already though. Doesn't that
> > count for something? :)
> >
> > Or, a bit more likely case, I know the type of the package, the
> > category, but don't recall it's exact name. What y'all are proposing
> > forces the user to use a tool, rather then just a quicky ls.
>
> *tongue in cheek* and what is ls but another tool for listing the
> contents of a directory :)

ls does no good if you're trying to see all packages of a category,
under this proposal, which is what I'm driving at. It forces the user
to use scripts/tools to do querying.

> >>I personally want to see the category part *disappear* from the *DEPEND
> >>which is one of the reasons to advocate a flat tree. If the category (or
> >>part of it) goes in the package name, so be it, but at least there will
> >>be no package moves to break older ebuilds or outdated overlays.
> >
> > Frankly, you need to give a *really* damn good reason for why this is
> > better. I don't think it is, convince me otherwise.
> >
> > What do we gain from a flat namespace?
> > Right now, I can infer an atom out of a DEPEND string's purpose to
> > some degree, based upon it's category. To head off the "well you
> > don't need to know the category, you should know the packages
> > intentions if you're modifying the ebuild", that dodges the point; via
> > the category portion of an atom, I can infer at least -intention- of a
> > package.
>
> The CPV thing.....is a big fix :(
>
> > Ignoring changes required (have stated them already, no point in
> > sniping ya over it), what _exactly_ do we gain from the change?

So... what do we gain? Like I said, ignore for a second that massive
overhaul required; if work is required to gain something, and what's
gained is worth it over the work, sure. I'm not seeing the gain
though :)

The original request was having a package turn up in multiple
categories for searching, right? I don't like it, but metadata.xml at
the package level could probably be extended for that, *strictly* for
searching. It cannot, *ever* be used for satisfying an atom imo.
Reason being it allows for the cpv conflict, rather then just package
conflicts we have now.
~Brian
--
gentoo-dev@gentoo.org mailing list

On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| 1) Human. It's frustrating to do emerge sudo and have it tell you to
| specify, when there's only /one/ "normal" sudo. The /other/ sudo
| should be vim-sudo or whatever, as you mention later.

Silly. Then you'd *always* have to give the full name of a package when
merging, in effect... emerge sys-devel-gcc rather than emerge gcc with
emerge sys-devel/gcc as a fallback, for example.

--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types
> On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | 1) Human. It's frustrating to do emerge sudo and have it tell you to
> | specify, when there's only /one/ "normal" sudo. The /other/ sudo
> | should be vim-sudo or whatever, as you mention later.
>
> Silly. Then you'd *always* have to give the full name of a package when
> merging, in effect... emerge sys-devel-gcc rather than emerge gcc with
> emerge sys-devel/gcc as a fallback, for example.

But we are only arguing of getting the categories (partially) in the
package name only where there is a necessity. The example with sudo is
with app-admin/sudo being strictly sudo, and app-vim/sudo being
vim-sudo. So we keep the current names except for those that clash, and
even there only change as little as possible.

--
> Georgi Georgiev > To be who one is, is not to be someone >
< chutz@gg3.net < else. <
> +81(90)2877-8845 > >

maillog: 11/05/2005-10:33:23(-0500): Brian Harring types
> The original request was having a package turn up in multiple
> categories for searching, right?

Actually, that was a side effect. The original request was to stop
moving packages around, which is the most annoying part and is also the
part that consumes a lot of effort. After all, this started as a result
of a discussion about the new name of a category. There were also talks
about whether some package should be in here or there... Having a flat
tree is one way to solve the discussed problem and which would also
allow me to find some package quickly. The flat tree request I, at
least personally, am willing to drop if you offer an alternative
solution to the keep-them-package-atoms-fixed-once-and-for-all problem.
Ahem, by an "atom" in this sentence I was referring to the CP part of
CPV.

--
\/ Georgi Georgiev \/ When all other means of communication \/
/\ chutz@gg3.net /\ fail, try words. /\
\/ +81(90)2877-8845 \/ \/

On Thu, 12 May 2005 02:21:28 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| maillog: 11/05/2005-16:41:37(+0100): Ciaran McCreesh types
| > On Tue, 10 May 2005 22:59:42 -0700 Duncan <1i5t5.duncan@cox.net>
| > wrote:
| > | 1) Human. It's frustrating to do emerge sudo and have it tell you
| > | to specify, when there's only /one/ "normal" sudo. The /other/
| > | sudo should be vim-sudo or whatever, as you mention later.
| >
| > Silly. Then you'd *always* have to give the full name of a package
| > when merging, in effect... emerge sys-devel-gcc rather than emerge
| > gcc with emerge sys-devel/gcc as a fallback, for example.
|
| But we are only arguing of getting the categories (partially) in the
| package name only where there is a necessity. The example with sudo is
| with app-admin/sudo being strictly sudo, and app-vim/sudo being
| vim-sudo. So we keep the current names except for those that clash,
| and even there only change as little as possible.

So we end up not using upstream naming, leading to major hassle with
tarballs, major user confusion and inconsistent naming (why are some vim
things vim- and others not?). Bad! Now that portage *tells* you when you
need to be more specific, there's no problem with name matches.

--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

maillog: 11/05/2005-19:06:37(+0100): Ciaran McCreesh types
> So we end up not using upstream naming, leading to major hassle with
> tarballs, major user confusion and inconsistent naming (why are some vim
> things vim- and others not?). Bad! Now that portage *tells* you when you
> need to be more specific, there's no problem with name matches.

I'll agree with you here. There doesn't seem to be an easy way to decide
what package will get a part of a category in its name. I was going to
propose a "plugins/extensions for an application get the name of the app
prepended + dash", but there would surely be others that will prove me
wrong.

I am giving up on arguing a point that involves too much effort for too
little gain. So, considering that the flat-naming is not feasible (I
cannot counter some of the point that were made against it, the above
being one of them) I'd like to stop shooting out ideas and restate the
problem that I think needs to be solved:

How do we prevent a current category/package combination like
net-wireless/gnome-phone-manager from becoming something else like
app-cellphone/gnome-phone-manager?

More preceisely, what I'd like to see, in order of preference, is

- that package in my overlay that has net-wireless/gnome-phone-manager
in its *DEPENDs to work for as long as needed
- the net-wireless/gnome-phone-manager that I have in my overlay to
work for as long as needed
- my net-wireless/gnome-phone-manager binary packages to work without
having to be "fixpackage"d
- the location of the ebuilds for net-wireless/gnome-phone-manager to
stay in the same physical path on my filesystem

--
\/ Georgi Georgiev \/ Weiner's Law of Libraries: There are no \/
/\ chutz@gg3.net /\ answers, only cross references. /\
\/ +81(90)2877-8845 \/ \/

On Thu, 12 May 2005 04:01:17 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| How do we prevent a current category/package combination like
| net-wireless/gnome-phone-manager from becoming something else like
| app-cellphone/gnome-phone-manager?

Two options:

* Smarter updates handling by portage. For example, maybe it could
realise that the package in question has been moved, and automatically
do the update (along with a QA notice: assumed package move blah). This
would also help for those unfortunate times when we don't manage to do a
huge package move in under the required half an hour.

* Unique ID strings for packages, zynot style. Messy as hell though,
DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
the same kind of ring to it...

--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Wed, May 11, 2005 at 08:10:03PM +0100, Ciaran McCreesh wrote:
> On Thu, 12 May 2005 04:01:17 +0900 Georgi Georgiev <chutz@gg3.net>
> wrote:
> | How do we prevent a current category/package combination like
> | net-wireless/gnome-phone-manager from becoming something else like
> | app-cellphone/gnome-phone-manager?
>
> Two options:
>
> * Smarter updates handling by portage. For example, maybe it could
> realise that the package in question has been moved, and automatically
> do the update (along with a QA notice: assumed package move blah). This
> would also help for those unfortunate times when we don't manage to do a
> huge package move in under the required half an hour.
That requires _active_ translation of deps. The current
search/replace type hackery is binpkg/vdb based, doesn't do jack for
ebuilds that still point at the old location.

> * Unique ID strings for packages, zynot style. Messy as hell though,
> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> the same kind of ring to it...
Actually... iirc, at least internally the unique 'key' for a cpv
that's being kicked around collapses cat/pkg/slot/use. Not much for
tacking on more metadata, since the unique key/id bit above still
requires active translation of deps as they're encountered.

No really easy way to dodge that, nor does it sound like stable
material. (my opinion mind you).
~brian
--
gentoo-dev@gentoo.org mailing list

On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>
> * Unique ID strings for packages, zynot style. Messy as hell though,
> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> the same kind of ring to it...

Maybe I'm just a messy person, but I really like this. It prevents
upstream naming collisions & opens multiple categories per package
completely. Mr Harring will hate it, but the rest of us will use
`esearch -o "%p\n" "" | grep -e category -e keyword`.

Stroller.

--
gentoo-dev@gentoo.org mailing list

On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
> >
> > * Unique ID strings for packages, zynot style. Messy as hell though,
> > DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
> > the same kind of ring to it...
>
> Maybe I'm just a messy person, but I really like this.
So does Microsoft. The registry has many entries where 128bit (?)
object-IDs are used. Very interesting to debug.
> It prevents upstream naming collisions
But reduces readability for humans to zero. We don't want that.

> & opens multiple categories per package
> completely. Mr Harring will hate it,
At least you haven't tried to optimize it all by using XML ...
> but the rest of us will use
> `esearch -o "%p\n" "" | grep -e category -e keyword`.
*head explodes*
No.

As much as I like the idea of a "better" portage, a binary obfuscation
won't help. It might make portage more resilient to one kind of problem,
but forget debugging then.

Patrick

Brian Harring wrote:
> > The layout on disk and the semantics of categories do not need to be > > related.
> Yes and no. You're assuming that people don't use the layout on
> disk for digging around without calling portage. Personally, I do.

Sometimes I do the same; but other times I find the layout a barrier. Many's the time I've done:

$ ls -d /usr/portage/*/<package name pattern>

to find a package, for example - that indicates the categories are actually hindering searches in this case. Incidentally it also treats the tree as if it were a flat namespace.

However, ideally I wouldn't be searching the tree directly like that at all, I'd be searching metadata based on various criteria. Indeed package names as they stand are frequently uninformative; if you decide you need something for a particular function, you can have a look in what you think may be the relevant categories, only to find a list of mostly meaningless package names. Then you start grepping the DESCRIPTIONs, and so on finally trying equery. This whole process is rather unsatisfactory, and in my experience often fruitless. Many times I've gone the other way; google for something to find candidate package names, then 'ls -d /usr/portage/*/<name>' to see if some kind soul has already added an ebuild to the tree.

For me, the whole point of a flat namespace is to _remove_ categories from the atom. Obviously this has far-reaching disruptive consequences as you describe, and in practice is not workable in the short to medium term at least.

I'd like to be able to ask questions like, "what app-text packages exist for <some function>?". At the moment, listing app-text, grepping app-text/*/*ebuild may get somewhere, but what about packages placed in different categories for reasons like name clash, other functionality and so on?

Cieran McCreesh wrote:
> So we end up not using upstream naming, leading to major hassle with
> tarballs, major user confusion and inconsistent naming (why are some vim
> things vim- and others not?). Bad! Now that portage *tells* you when you
> need to be more specific, there's no problem with name matches.

I agree maintaing upstream naming is very important. However obviously upstream names can and do clash. That raises the question of how such clashes should be resolved. Categories are a rather arbitrary way of doing that - it's quite possible that a clash could occur between two packages that naturally fall into the same category - in the current system that means one of the packages gets dumped in a second-choice category.

Talking atoms, one could handle clashes by differentiating occurrences with an extension to the name. To take the sudo example, sudo could be the normal sudo, sudo:vim (or perhaps sudo__vim to be acceptable to more filesystems) could be the vim extension sudo.

Brian Harring wrote:
> Re-asserting that the fs layout *does* matter, how is that more intuitive > when trying
> to track down the ebuild for dev-util/diffball ? How many directories > deep would I have to go before I reached the ebuild?

$ ls -d /usr/portage/*/<name pattern>

becomes

$ find /usr/portage -type d -name <name pattern> -print

and for quick&dirty things like

$ grep -l <pattern> /usr/portage/*/<name pattern>/*ebuild

instead do:

$ find /usr/portage -type d -name <name pattern> \
-exec grep -l <pattern> \{\}/*ebuild \;

or somesuch.


An interesting possibility is that the portage mirrors and clients can have different layouts depending what is most suitable. Those with reiserfs could sensibly choose the very wide layout. Others on ext2 could choose a s/u/sudo approach to avoid problems with very wide directories. Obviously this means modifying the sync process somewhat deal with this, but it's quite possible, in a scalable efficient manner.

Brian Harring wrote:
> > The key here is to separate the category (metadata) and filesystem [snip]
> This also locks out several possibilities, like relying on dir structure > to limit the searches.
> You force category classification to be metadata, you need an additional > db to do searching,
> and basic atom lookup. That's 19000+ keys in a db. No db, and you force > a tree wide search, which _will_ be as fast as emerge -S is.

If you retain category in the atom; for me there's no point flattening the namespace without removing the category completely from the atom.

Where at the moment you perhaps want to do:

$ grep <pattern> /usr/portage/app-text/*/*ebuild

then yes, an additional db of some kind is necessary, or perhaps a more efficient way of searching the metadata.xml files. However I disagree with the 19000+ keys. Portage could for example maintain a simple category->package name mapping - only needs to be updated when packages are added/removed from the tree or metadata is changed, and can be trivial. For example, it could be a simple shell script with entries like:

PC_<category>=<name> <name> <name>

at which point you only need to do:

$ source <category db>
$ for pkg in ${PC_<category>}; do ... ; done

Brian Harring wrote:
> cpvs can't conflict, pure and simple under the current
> layout, which is
> enforce by the single category/fs layout.

cpvs can't conflict because when a package name already exists in a category, a conflicting package name has to go into a different category even if it's not the most natural category for the package. What you've done there, is assert a rule (cpvs are unique) thus

Brian Harring wrote:
> What are we gaining? Ability to find a package under two categories?

That, and stability of package location. Moving packages around the tree is disruptive, not just to ebuilds that reference them but also cause unnecessary mirror activity.

For me, categories are a search criteria. Making them part of the tree makes it difficult to revise those criteria.

Brian Harring wrote:
> > The benefits include
> > 1) no more "moving packages around the tree"
> cpv conflict. You aren't moving the fs position of it, but it still
> requires walking the tree and updating all atom's that reference the old > position.
The point is that *DEPEND would not mention the category.

Brian Harring wrote:
> > 2) categories can be added to a package in the most natural way
> Elaborate.

The idea is that packages can naturally belong in more than one category. Thinking of categories more like search keywords, if you like. A package that processes text would match app-text, but perhaps it's also a financial tool which would therefore also match app-finance.

Another good example of the usefulness of more than one category are the sys-* categories, where all the packages in sys-* categories naturally fall both into their sys- category but also the relevant non-sys category. Take GCC; currently in sys-devel/gcc, not in dev-lang/gcc which is where a naive user would look for it. With multiple category markings, it could be in both.

Brian Harring wrote:
> > 3) overlays can be tidier
> Eh?

This is a result of the dynamic s/u/sudo approach where the directory depth is arbitrary. In the overlay you could drop the s/u/ bit. I'd guess most overlays modify relatively few packages; I know I have a bunch of categories in my overlay that only contain one package. Given that portage would take a top-down search approach to locate the package (i.e. try sudo, then s/sudo, then s/u/sudo ... first in overlay then in the mirror) this works transparently.

Brian Harring wrote:
> What do we gain from a flat namespace?

Eliminating categories from package names

> Right now, I can infer an atom out of a DEPEND string's purpose to
> some degree, based upon it's category.

You could use this argument for appending the description to the atom, but noone would suggest such a thing seriously. What you're justifying, is building metadata into the package name.

> To head off the "well you
> don't need to know the category, you should know the packages
> intentions if you're modifying the ebuild", that dodges the point; via > the category portion of an atom, I can infer at least -intention- of a > package.

To be more accurate, you can infer an aspect of the intention of a package that the original committer felt was most important whilst avoiding clashes. That's the point - by forcing a package to be a member of exactly one category, the implications from category membership are limited.


I'm the first to admit that doing the changes to the fs layout I've talked about are hugely disruptive, and as such are not sensible, most especially in the short to medium term. This discussion however does serve to understand the problem properly before making any changes. I think adding categories to metadata.xml, removing the few clashes (but otherwise leaving the fs layout as it is), and coming up with an efficient search tool (e.g. getting portage to maintain something like the script I mentioned above, or creating a widget to build it from the metadata.xml files) could eliminate the primary problem of moving packages around, and the arguments like should a package be in dev-cpp or dev-libs. The rule could then be that once a package is in a physical category in the tree then it will not physically move, no matter what. *DEPEND would continue to use the physical category, at least in the short term - it could ultimately drop the category if that becomes sensible. !
Changing the few existing clashing names could be undertaken gradually (e.g. appending :<differentiator> as describe above), to allow clashing names to belong to the same category.


This is quite benign and relatively painless. Ultimately you have a flat namespace, packages will no longer move inside the fs tree, the old q&d ls/grep tricks to try to find suitable packages would work as well as they do now, arguments about which category to place a package disappear, searches using category can become more intuitive, different packages that have the same upstream name can be members of the same category.

Kev.



--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stroller wrote:
>
> On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
>
>> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
>>
>>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>>>
>>>>
>>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
>>>> the same kind of ring to it...
>
>
> I'm going to ignore that. This thread started because the current
> category/name naming convention causes interesting conditions. I
> appreciate that generally Microsoft Are Not Our Favourite Software
> Company, but giving them as an example doesn't inherently make unique
> IDs bad, and 128-bit ones are not necessary in this case.
>
32-bit (unsigned) should be plenty ;)
>
>>> It prevents upstream naming collisions
>>
>> But reduces readability for humans to zero. We don't want that.
>
>
> Humans are used to dealing with indexes - we remember phone numbers
> easily, and if we're looking up several things in a large volume, then
> we're used to using bookmarks or noting down page numbers. A six figure
> decimal packageID allows for a million packages in the Portage tree (and
> I'm assuming versions will be separate, anyway), a five figure hex ID
> would allow far more.
>
>> At least you haven't tried to optimize it all by using XML ...
>>
>>> but the rest of us will use
>>> `esearch -o "%p\n" "" | grep -e category -e keyword`.
>>
>> *head explodes*
>> No.
I think there are a few points that are at the core of this.
A. Categories are metadata. Not many people like doing this,
especially since you are sorting by a particular metadata that isn't
unique in all cases ( or shouldn't be ). If people want to sort by
something else, it too should be unique, hence the GUID crap above.
This might kill off names ( do we not want a package have 2 names, or 2
packages having the same name? ).

B. Users don't care how the data is stored, they will create/use tools
to search through it. I think this is much different than the
developer's view. As a user, if I am looking for a package I'll use
emerge -s or p.g.o. I don't go diving into the tree unless I'm looking
for an ebuild and I doubt that many users actually go ebuild diving.
This creates issues where developers need to get to ebuilds to check out
issues, and users want fast searching. One is condusive to human
readability, the other is to computer readability.

Is human readability worth it here, and is there a storage mechanism
that gives us both? Certainly the current system works, albeit with
some limitations that some people do not like. IMHO I think the flat
tree sucks too, but I haven't put much thought into any other storage
mechanism. Certainly it would be nice if one machine held the database
on a SQL server and each client just made queries, although it would be
much slower :)

I should also note that ripping categories out of CPV's means a lot of
work on internals; I think it's worth it to spec things out now since a
lot of other stuff is being gutted anyway.

- -Antarus

> Stroller.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoNDzGzglR5RwbyYAQJaVQ//ZsFJzSkm35bo87SAwUqtWKjOvOn6CUph
2vdOfnjIjJQkhgeew8RMp/f+TiKuCT8t0WVtTKsS5mLeno2WXkqetbfVayfsT29L
kMqp42LUDPBEHe+aOMn8TlKjCvPpNow4TWecFEoaV6MF4sutxyP3+cg6Noay7hiF
mvGahADLpuENNaLpmy0ETs6oh4UeReI6PBl6QrO46uj9kL3HnFxPRncp+52Q0KHh
44uoqcGu4PYF5YfTHqyA71Ibg9SPKPUGxHbs53ISVmhWRWuRs6l+3N7aXyap5ChV
iBMsAzns0xMAuV25BoPTmdyQSyJBAXfXCtAWJ0PcFRx5lnMvVJ95McXjjeINbG60
dWJQ1q1CKeOIVnm6JScwtkELm1yXIKnQ8wqpSevC+xrNUwJCth/g6pHvSPZhw9ng
R6nTpwd8DWwUJ7j90L7Aggf2vB2+f/u2c03er120PKiAMJIJtLXHJlLrkGH8/MkT
F1fol4TF4i4sLXJ+kceoOFHEgT70kmQXpdzTMfhcm3BAIBxTDGkjWS5+U+3K3wCj
3fgxm/28B9b396cdoXWDOgV9C1kEe1IkC+GKe6CmFqIiP70Ov4eGgj3ejSabY5YV
OWiPKMeLPjZtL5H4359k6S2U42zJI9BJUoJgFP9iQhhMA8Io+GLKVwwv+5Jd+V9l
BoHjO7tPWmw=
=nJ6R
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On May 12, 2005, at 10:11 am, Patrick Lauer wrote:
> On Wed, 2005-05-11 at 23:58 +0100, Stroller wrote:
>> On May 11, 2005, at 8:10 pm, Ciaran McCreesh wrote:
>>>
>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't
>>> have
>>> the same kind of ring to it...
>>
>> Maybe I'm just a messy person, but I really like this.
> So does Microsoft. The registry has many entries where 128bit (?)
> object-IDs are used. Very interesting to debug.

I'm going to ignore that. This thread started because the current
category/name naming convention causes interesting conditions. I
appreciate that generally Microsoft Are Not Our Favourite Software
Company, but giving them as an example doesn't inherently make unique
IDs bad, and 128-bit ones are not necessary in this case.

Also, before I start, I'd like to say that I know I'm not qualified to
advocate this as a serious suggestion for adoption by Gentoo, so I'm
just explaining _why I like it_.

>> It prevents upstream naming collisions
> But reduces readability for humans to zero. We don't want that.

Humans are used to dealing with indexes - we remember phone numbers
easily, and if we're looking up several things in a large volume, then
we're used to using bookmarks or noting down page numbers. A six figure
decimal packageID allows for a million packages in the Portage tree
(and I'm assuming versions will be separate, anyway), a five figure hex
ID would allow far more.

Yes, arbitrary unique IDs would require an index tool to access ebuild
name / category data, but surely there is little choice if
naming-collisions are to be avoided and multiple categories are
desired? Surely any human-focused naming convention will cause
collisions and introduce potential for confusion? The current
categories divide collisions into separate spaces, but they don't solve
the problem of foo-player being eligible for both the media-CDplayers
and audio-mp3rippers categories.

> At least you haven't tried to optimize it all by using XML ...
>> but the rest of us will use
>> `esearch -o "%p\n" "" | grep -e category -e keyword`.
> *head explodes*
> No.

That's the first time I used that command, but it only took me two
minutes to look up & test. Since a dedicated index tool would clearly
be required, I'm sure it would have better & more useful syntax.
Currently I assume that Mr Harring searches for all the applications in
a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it
be easier to use `esearch --category country`. Not only would it list
them all, but multiple categories per package would also allow those to
be shown that might debatably be categorised as "western".

> ...It might make portage more resilient to one kind of problem,
> but forget debugging then.

Do we have 65000 unique packages in the tree? Would a four figure hex
"part number" be that hard to remember when you're debugging package
names?

Again: I know I'm not qualified to advocate this as a serious
suggestion for adoption by Gentoo, so I'm just explaining _why I like
it_.

Stroller.

--
gentoo-dev@gentoo.org mailing list

On Thu, May 12, 2005 at 08:01:23PM +0100, Stroller wrote:
> >>>* Unique ID strings for packages, zynot style. Messy as hell though,
> >>>DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't
> >>>have
> >>>the same kind of ring to it...
> >>
> >>Maybe I'm just a messy person, but I really like this.
> >So does Microsoft. The registry has many entries where 128bit (?)
> >object-IDs are used. Very interesting to debug.
>
> I'm going to ignore that. This thread started because the current
> category/name naming convention causes interesting conditions. I
> appreciate that generally Microsoft Are Not Our Favourite Software
> Company, but giving them as an example doesn't inherently make unique
> IDs bad, and 128-bit ones are not necessary in this case.
I suspect his point was that a 128-bit ID is holy hell on frail
humans, versus a category/package string (which isn't).


> >> It prevents upstream naming collisions
> >But reduces readability for humans to zero. We don't want that.
>
> Humans are used to dealing with indexes - we remember phone numbers
> easily
Majority of the population don't have 1000+ phone numbers memorized
though (which is roughly what we're talking about here for the package
equiv).

> and if we're looking up several things in a large volume, then
> we're used to using bookmarks or noting down page numbers. A six figure
> decimal packageID allows for a million packages in the Portage tree
> (and I'm assuming versions will be separate, anyway), a five figure hex
> ID would allow far more.
Heh, counter example. Consider cell phones, people search for numbers
based upon arbitrary names associated with the digits (one could view
our category/package bit as the same).

> Yes, arbitrary unique IDs would require an index tool to access ebuild
> name / category data, but surely there is little choice if
> naming-collisions are to be avoided and multiple categories are
> desired? Surely any human-focused naming convention will cause
> collisions and introduce potential for confusion? The current
> categories divide collisions into separate spaces, but they don't solve
> the problem of foo-player being eligible for both the media-CDplayers
> and audio-mp3rippers categories.
One problem, still need to resort to a human readable representation
for specifying depends. Stating DEPEND="mpeg? ( \d{16} ) \d{16}"
would be hell on devs. An automated approach could be leveled, but
would need a *really* good reason to explain the loss of DEPEND
readability via an editor.

> >At least you haven't tried to optimize it all by using XML ...
Antarus, was that you who tried the cache backend using xml? ;)

> >>but the rest of us will use
> >>`esearch -o "%p\n" "" | grep -e category -e keyword`.
> >*head explodes*
> >No.
> That's the first time I used that command, but it only took me two
> minutes to look up & test. Since a dedicated index tool would clearly
> be required, I'm sure it would have better & more useful syntax.
> Currently I assume that Mr Harring searches for all the applications in
> a category by typing `ls -d /usr/portage/app-category/*` - wouldn't it
> be easier to use `esearch --category country`. Not only would it list
> them all, but multiple categories per package would also allow those to
> be shown that might debatably be categorised as "western".
actually... I use emerge -s @category
emerge's speed is an issue granted, but not a reason to restructure
(the speed issue isn't related to it, it's initialization overhead of
import portage).

> >...It might make portage more resilient to one kind of problem,
> >but forget debugging then.
>
> Do we have 65000 unique packages in the tree? Would a four figure hex
> "part number" be that hard to remember when you're debugging package
> names?
Yeah, imo. What gain is there in having to memorize 1623 is openssh,
just so I can comprehend the DEPEND string when glancing over an
ebuild?

> Again: I know I'm not qualified to advocate this as a serious
> suggestion for adoption by Gentoo, so I'm just explaining _why I like
> it_.
content is what matters, not the speaker or his/her qualifications :)
~brian
--
gentoo-dev@gentoo.org mailing list

Stroller wrote:
>>>> * Unique ID strings for packages, zynot style. Messy as hell though,
>>>> DEPEND="foo/bar {12379812AD7382164BD87678652438FC65E43A2}" doesn't have
>>>> the same kind of ring to it...
[snip]
> I'm going to ignore that. This thread started because the current
> category/name naming convention causes interesting conditions. I
> appreciate that generally Microsoft Are Not Our Favourite Software
> Company, but giving them as an example doesn't inherently make unique
> IDs bad, and 128-bit ones are not necessary in this case.

Actually ciaranm's example contained 39 hex digits, which leads to
624bit IDs :-).

-jkt

--
cd /local/pub && more beer > /dev/mouth

Alin Nastac wrote:
> Hi folks,
>
> I think we should make a new category called app-cellphone containing
> the following packages:
> net-dialup/gammu
> net-dialup/gnokii
> net-dialup/wammu
> net-wireless/gnome-phone-manager
>
> Yes, I know. It is a short list, but shouldn't be a category
> representative for its content?

net-wireless/obexftp
net-misc/sms
net-misc/linuxsms
net-misc/ksms
net-misc/gsmlib
net-misc/esms
media-sound/bemused
media-plugins/xmms-btexmms
kde-misc/kmobiletools }
kde-base/kandy } these could probably stay in kde
app-pda/x70talk
app-pda/bitpim
app-misc/ringtonetools

this doesn't include anything like VOIP of course. btw i think
"cellphone" is an Americanism. i worked for AT&T Wireless before they
were bought by Cingular and the term "cellphone" was discouraged for
that reason. maybe just app-phone?

--de.

--
gentoo-dev@gentoo.org mailing list

Martin Schlemmer posted <1115715727.25756.8.camel@nosferatu.lan>,
excerpted below, on Tue, 10 May 2005 11:02:07 +0200:

> Problem with flat tree, is the search times might then suck even more, as
> last I heard, too many dirs/files in one directory have a huge speed
> penalty.

Yeah, sure, for ext2/3, but all those small files would suck big time in
ext2/3 anyway. Reiserfs doesn't have either issue, and should be perfect
for portage trees, even for those who still think the reliability isn't
there (I've been /very/ happy with it here, since the data=ordered
default went into the kernel for reiserfs, even when I had defective
memory and was hard-locking fairly frequently due to that), because
portage trees are a simple sync away from replacing anything lost.

I never remember which one it is, but either jfs or xfs has packed files
as a feature as well, IIRC, so the small file sizes works, altho I believe
it'd still have issues with high file-count dirs.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Stephen Bennett posted <1115739418.24940.5.camel@localhost>, excerpted
below, on Tue, 10 May 2005 16:36:57 +0100:

> On Tue, 2005-05-10 at 11:05 -0400, Alec Warner wrote:
>> I'll be the first alt-arch person to scream, Reiser isn't stable on more
>> than half the arch's we support, and forcing users to go to one
>> filesystem just to get decent speed on portage tree searches is silly.
>
> Besides which, as of latested released kernels Reiser still doesn't have
> working extended attributes, so SELinux systems can't mount it. Apparently
> there's a patch kicking around, but forcing people to patch kernels
> themselves is even sillier.

Well, the latter anyway shouldn't be a big issue. That's what Gentoo
ships patched kernels for, right? ... And as for not stable on various
archs, that's what open source is for, right? (Leastwise I always see
complaints from others and have complained myself about that being one of
the problems with Java, not available in decently recent form on many
archs because it's not open for those motivated enough to make it work,
when those that /have/ the source refuse to do so, to do so themselves.
Said as I (im)patiently wait for reiser4 to stabilize on amd64, because I
regrettably don't have the skill set required to help get it there. =8^\)

Anyway, I wasn't necessarily arguing for a flat portage dir tree, but
simply pointing out that the problem of too many file/dir entries in a dir
has a known and open source solution, therefore, that problem by itself
isn't that big a deal. In practice, the flat-logical tree, organized by
letter, would probably be easier to work with, because regardless of the
ability of technology to handle the disk layout efficiently, humanity
doesn't scale so fast, and more than a few hundred entries simply gets
hard for the humans to work with, even if the file system has no problem
with it. The file system problem may be solved, but the human problem is
something else entirely (and tab completion doesn't work for
/everything/). Thus, really what I'm saying is don't deal with the
small, already solved stuff, when there's far larger unsolved problems --
if it's taken to be a flat dir layout, anyway -- that could be mentioned.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Brian Harring posted <20050511050920.GC17034@exodus.wit.org>, excerpted
below, on Wed, 11 May 2005 00:09:20 -0500:

> One thing that just clicked in the skull on why flat-tree has issues;
> currently it's possible to have a package with the same name, yet a
> differing category (app-vim/sudo vs app-admin/sudo).
>
> Since our tree layout is based upon category, if you tried shifting the
> focus of it to packages_in anyway_, you would explicitly disallow same
> name packages, different category. Doesn't matter how you structure the
> tree, if you do lookup into the tree based on package, not category, you
> disallow same named packages.

While I'm not a flat tree supporter per se, duplicate packages are IMO a
bad thing in any case, for two reasons.

1) Human. It's frustrating to do emerge sudo and have it tell you to
specify, when there's only /one/ "normal" sudo. The /other/ sudo should
be vim-sudo or whatever, as you mention later.

2) Bin-pkgs. As currently structured, we have a de-facto "flat" bin-pkgs
layout anyway, since the tree is simply a bunch of symlinks pointing to
the $PKGDIR/All dir that /all/ the packages land in. Clashing packages is
NOT a good thing, as I'm sure you are aware. /Something/ really needs to
be done about this one. Any possible light at the end of the tunnel here?

BTW, it'd be very handy to have "slotted" bin-pkgs as well, "slotted" as
in allowing me to do things like test a gcc4 created package, without
erasing my gcc-3.4 created bin-pkg, in case something doesn't work, and
without having to remember to manually copy/move the existing bin-pkg
first to keep that backup. A feature to enable some arbitrary identifier
in the binpkg name, or an arbitrary string as a binpkg subdir path
fragment, would be very helpful. Something like FEATURES=binpkg-name then
enabling a BINPKG-NAME=gcc4, to then either create a $PKGDIR/gcc4 subtree,
or $PKGDIR/All/package-version.gcc4.tbz2 type package and appropriate
symlink. One could then just remember to change the $BINPKG-NAME entry in
make.conf whenever one runs gcc-config, or whenever one triggers whatever
switch and desires a corresponding binpkg-slot change. Anything like this
in the works? Should I file an enhancement bug? Maybe the ability is
there already and I just don't know it, as with the very cool make.conf
"source" feature I saw mentioned on the amd64 list?

BTW2, does the "." shortcut work in make.conf? I can envision a make.conf
that's simply a half dozen or so lines of "source
/etc/portage/make.network.conf", ". /etc/portage/make.useflags.conf", etc.
Is that documented anywhere, yet? When (version) was it introduced?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Brian Harring posted <20050511065023.GE17034@exodus.wit.org>, excerpted
below, on Wed, 11 May 2005 01:50:23 -0500:

> Umm. yes?
> Cleanup of stuff in general is in the works, including (done when it's
> done) binpkg handling being tweaked, which may or may not cover the
> huge-ass block of requests above :)

I see I didn't effectively convey what I wanted, then, if the description
is a "huge-ass block of requests". =8^) Let's see if I can reword it a
bit more effectively...

What I had in mind (and tried to describe), was a /single/ (if large)
/general/ feature, call it FEATURE=binpkg-name, to be combined with a
second parameter enabled by that feature, BINPKG-NAME=<whatever>.
<whatever> would then either be a) created as a subdir of the existing
$PKGDIR, or b) appended to the name of the package in the existing dir,
preferably creating a double-extension, as in bash-3.0-r11.gcc4.tbz2, if
(as in my example, the reason I'd presently find this useful)
BINPKG-NAME="gcc4".

Thus, for this specific use, I'd either a) have a $PKGDIR/gcc4 subtree in
addition to the normal $PKGDIR subtree (which would be equivalent to
BINPKG-NAME=""), or b) have individual packages such as
bash-3.0-r11.gcc4.tbz2, as well as possibly having the normal
bash-3.0-r11.tbz2, with the feature or BINPKG-NAME var unset.

However, as envisioned, the feature would be generalized enough to allow
all sorts of other uses as well, perhaps for MULTILIB (MULTIAPP??) folks,
a separate 32-bit and 64-bit copy of the same package, use of the same
general $PKGDIR location with different archs due to the possible subtrees
(or subnames), or for any other sort of testing or local use where
creating a binpkg that doesn't overwrite a previous version might be
useful. The key here is that the feature as implemented would be general
enough to allow all sorts of local flexibility as to how it was used.

So far, I've only discussed portage binpkg creation. Use of those
additional binpkg subtrees/subnames could remain manual only, requiring
the user/admin to shuffle the desired binpkg back into the default
location, and still be quite useful. Alternatively, and probably when
the second half of implementation is complete, portage would account for
the feature, and if it was on read the var and draw from the appropriate
subtree/subname (a or b options above) as configured.

/IF/ that makes any more sense... Single feature, implemented as a toggle
feature with a var pointer, thus generalizing the use.

If the above were to be implemented, gcc-config could then possibly take
advantage of it, appending to the local installation set BINPKG-NAME var
for experimental versions of gcc. If the feature was set, it would then
automatically create its own experimental binpkgs which wouldn't overwrite
existing versions. If the feature was unset, setting BINPKG-NAME
wouldn't have any effect.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Georgi Georgiev posted <20050511071048.GA2445@ols-dell.gg3.net>, excerpted
below, on Wed, 11 May 2005 16:10:48 +0900:

> PKGDIR=/usr/portage-pkg/gcc4 emerge -B app-admin/sudo
>
> That ought to do what you want it to do. But then, portage will be unable
> to untar-uncompress-sed/awk/whatever-tar-compress (refering to
> "fixpackages" by its full name here) the binary packages in your custom
> location if a package in there jumps categories. Wow, I managed to get
> back on topic :)

Hmm... Yes, I'm beginning to see this, now that the discussion seems to
be widening my viewpoint a bit. One of those "Duh, why didn't I see that
before?" moments on my part. <g>

I'm not sure as to the uncompress issue (as you followup with), but simply
setting a different PKGDIR location when I run gcc-config should do what I
wanted, and I can then simply switch back to the old tree if necessary
with a quick reset of PKGDIR.

Thanks for pointing that out!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

Duncan posted <pan.2005.05.11.10.03.13.603585@cox.net>, excerpted below,
on Wed, 11 May 2005 03:03:14 -0700:

> I see I didn't effectively convey what I wanted, then, if the description
> is a "huge-ass block of requests". =8^) Let's see if I can reword it a
> bit more effectively...
>
> What I had in mind (and tried to describe), was a /single/ (if large)
> /general/ feature, call it FEATURE=binpkg-name, to be combined with a
> second parameter enabled by that feature, BINPKG-NAME=<whatever>.

Never mind... It seems the feature I wanted is already there, only I
wasn't thinking broadly enough. Georgi Georgiev pointed it out...

My proposal would have allowed a bit more automation, but at FAR more
complexity. Better leaving well enough alone.

Portage's flexibility in sysadmin customizability continues to amaze me.
It really /is/ an awesome system Gentoo has built, when one thinks about
it. =8^) Sometimes in the minutia of discussion we (I, anyway) forget
just how awesomely flexible the existing toolset actually is!
Definitely "standing on the shoulders of giants", we owe drobbins and
indeed, the FBSD ports system from which he got a lot of inspiration, a
great deal of gratitude. That's not forgetting current developers, of
course. =8^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list