Gentoo Archives: gentoo-dev

From: Georgi Georgiev <chutz@×××.net>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New category proposal
Date: Wed, 11 May 2005 09:01:15
Message-Id: 20050511090116.GA3093@ols-dell.gg3.net
In Reply to: Re: [gentoo-dev] Re: New category proposal by Brian Harring
1 maillog: 11/05/2005-03:40:04(-0500): Brian Harring types
2 > > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote:
3 > > Here's my suggestion, for what it's worth :)
4 > >
5 > > The layout on disk and the semantics of categories do not need to be related.
6 > Yes and no. You're assuming that people don't use the layout on disk for digging
7 > around without calling portage. Personally, I do.
8 >
9 > > I like the idea of using the first character of a package name as the
10 > > sub-directory name. This can be extended more deeply as and when necessary to
11 > > avoid over-large directories which cause problems on some filesystems. e.g.
12 > > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is
13 > > architecture-neutral, rsyncable, scalable, and not too difficult for users to
14 > > parse manually (see later for searching through categories). If the algorithm
15 > > portage would use to locate a package is such that it doesn't mandate the depth
16 > > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/"
17 > > exists) then overlays can have a different depth to the rsync tree; if you only
18 > > have a few packages in overlay then they need not be in subdirectories at all.
19 > Re-asserting that the fs layout *does* matter, how is that more intuitive when trying
20 > to track down the ebuild for dev-util/diffball ?
21
22
23 The fact that the directory where diffball is is easily deducable by its
24 name. As it is, I'd be a bit lost if I had to guess whether diffball is
25 in app-arch or dev-util. Even if I remembered it was something
26 dev-related I'd still be inclined to look in sys-devel.
27
28 As it is, for those who don't use a given package on an everyday basis
29 the categories are extremely obscure.
30
31 > How many directories deep would I have to go before I reached the
32 > ebuild?
33
34 Does it matter? You know the path exactly. It's p/portage. It's
35 not ... "was it sys-apps/portage or app-portage/portage"?
36
37 ... skip a bit ...
38
39 > > Having said that, some things could be done now. If a flat package namespace
40 > > is desirable, the existing package name clashes could be resolved by renaming
41 > > the few packages that clash.
42 > 74 packages, roughly, out of 9429 roughly.
43
44 76/9295, which is not that bad, considering about half of them are
45 emacs/xemacs related.
46
47 > > Category could be added as a field in
48 > > metadata.xml, so that a package could "belong" to multiple categories.
49 > > The query/search tools could be enhanced to scan this metadata (perhaps including
50 > > the current category directory as an implied entry in the metadata.xml).
51 > If that's the goal of the "belong to N categories" thread, strictly searching,
52 > sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv
53 > nonconflicting bit.
54
55 I personally want to see the category part *disappear* from the *DEPEND
56 which is one of the reasons to advocate a flat tree. If the category (or
57 part of it) goes in the package name, so be it, but at least there will
58 be no package moves to break older ebuilds or outdated overlays.
59
60 --
61 \ Georgi Georgiev \ Taxes, n.: Of life's two certainties, the \
62 / chutz@×××.net / only one for which you can get an extension. /
63 \ +81(90)2877-8845 \ \
64 --
65 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Re: New category proposal Brian Harring <ferringb@g.o>