Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New category proposal
Date: Wed, 11 May 2005 08:39:36
Message-Id: 20050511084004.GB13132@exodus.wit.org
In Reply to: Re: [gentoo-dev] Re: New category proposal by "Kevin F. Quinn"
1 > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
2 > Here's my suggestion, for what it's worth :)
3 >
4 > The layout on disk and the semantics of categories do not need to be related.
5 Yes and no. You're assuming that people don't use the layout on disk for digging
6 around without calling portage. Personally, I do.
7
8 > I like the idea of using the first character of a package name as the
9 > sub-directory name. This can be extended more deeply as and when necessary to
10 > avoid over-large directories which cause problems on some filesystems. e.g.
11 > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is
12 > architecture-neutral, rsyncable, scalable, and not too difficult for users to
13 > parse manually (see later for searching through categories). If the algorithm
14 > portage would use to locate a package is such that it doesn't mandate the depth
15 > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/"
16 > exists) then overlays can have a different depth to the rsync tree; if you only
17 > have a few packages in overlay then they need not be in subdirectories at all.
18 Re-asserting that the fs layout *does* matter, how is that more intuitive when trying
19 to track down the ebuild for dev-util/diffball ? How many directories deep would I have
20 to go before I reached the ebuild?
21
22 The changes I posit aren't anymore friendly to devs doing ebuild work, and requires
23 a flat namespace- no conflicts, meaning that we have to choose alternate names for conflicts
24 (or the category data winds up in the name). Like I said, I really dislike debian's flat
25 namespace, even if we had a category component to it.
26
27 > The key here is to separate the category (metadata) and filesystem layout
28 > (implementation detail) from the concept of package name. This opens up all
29 > sorts of possibilities, for example different layouts in CVS, on mirrors and on
30 > clients (some kind of custom rsync would be necessary) - but that's going
31 > perhaps too far...
32 This also locks out several possibilities, like relying on dir structure to limit the searches.
33 You force category classification to be metadata, you need an additional db to do searching,
34 and basic atom lookup. That's 19000+ keys in a db. No db, and you force a tree
35 wide search, which _will_ be as fast as emerge -S is.
36
37 > Categories become metadata, formally (this is the root of the problem -
38 > including the category in the package name is a pollution of the package name).
39 > Once they become properly understood and implemented as metadata, a package
40 > being a member of more than one category is a natural consequence.
41 Currently, the only conflicts that can occur in searches are package specific. Atoms,
42 the basis of our depends system require categories; as such conflicts *cannot* occur.
43 Multiple categories per package allows for conflicts to occur in our deps. This is
44 nasty, and again, requires pretty much a walk of the whole tree to verify no conflicts
45 (mr_bones_, aka michael sterret would probably quietly curl up and die when his repoman runs,
46 which are now under an hour, clear 2 hours again) :)
47
48 > Portage would essentially ignore categories. Some support would be necessary
49 > to allow the user to query categories (since 'ls /usr/portage/<category>' would
50 > no longer work) - but searching for packages is already a function and would
51 > just need to be adapted (and perhaps optimised ;) ). Indeed just listing out
52 > portage directories at the moment is often insufficient to find a suitable
53 > package, since package names are often amusing but uninformative acronyms.
54 Portage can't ignore categories, see the bit above about cat/pkg-ver (cpv from this point
55 on) conflicts. cpvs can't conflict, pure and simple under the current layout, which is
56 enforce by the single category/fs layout.
57
58 What are we gaining? Ability to find a package under two categories?
59
60
61 > The benefits include
62 > 1) no more "moving packages around the tree"
63 cpv conflict. You aren't moving the fs position of it, but it still requires
64 walking the tree and updating all atom's that reference the old position.
65
66 > 2) categories can be added to a package in the most natural way
67 Elaborate.
68
69 > 3) overlays can be tidier
70 Eh?
71
72 > well, it's a big downside...
73 E'yep. :)
74
75 > Having said that, some things could be done now. If a flat package namespace
76 > is desirable, the existing package name clashes could be resolved by renaming
77 > the few packages that clash.
78 74 packages, roughly, out of 9429 roughly.
79
80 > Category could be added as a field in
81 > metadata.xml, so that a package could "belong" to multiple categories.
82 > The query/search tools could be enhanced to scan this metadata (perhaps including
83 > the current category directory as an implied entry in the metadata.xml).
84 If that's the goal of the "belong to N categories" thread, strictly searching,
85 sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv
86 nonconflicting bit.
87 ~brian
88 --
89 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Re: New category proposal Georgi Georgiev <chutz@×××.net>
Re: [gentoo-dev] Re: New category proposal "Kevin F. Quinn" <ml@××××××××.com>