Gentoo Archives: gentoo-portage-dev

From: George Shapovalov <george@g.o>
To: gentoo-portage-dev@g.o
Subject: [gentoo-portage-dev] few more portage-ng "feature proposals"
Date: Wed, 17 Dec 2003 02:53:01
1 Hi gang.
3 Here go a few more ideas I decided to throw in.
4 I must mention that these are mostly reiterations of some points that were
5 raised at different occasions in previous (and often old; yea, I really am
6 doing too much of "hey this was discussed like a year ago" stuff lately :))
7 discussions of portage functionality/enhancements. Thus effectively this is
8 going to be more of an overview than a new proposal. I did not seem to see
9 them mentioned yet, but in case some of them are dups I apologise.
10 So, here goes:
12 1. Multilevel categories. For example:
13 dev-* => dev/langs/{procedural/,functional/...}
14 lib/...
15 util/...
16 Support for arbitrary "deepness" is preferable.
17 The tree is getting bigger and bigger and this feature should keep it
18 browsable for some time to come. Addition of similar category browser to
19 would be nice too.
20 (I couldn't get through to it for some reason now to check if its not there.
21 So if it is I apologise :)).
23 2. Support for duplicate package names under different categories.
24 There was a (mildly) heated discussion some time ago on that one with may be
25 only silghtly more people on the pro side. Having dealt with my portion of
26 dups and having been in situation when already included package with the same
27 name complicates the (naming) issue I arrived to conclusion that it is
28 inevitable. The reality is that we already have couple of such dups and we
29 have to deal with this anyway (btw, even with present portage things seem to
30 work even if in a semisupported fashion).
32 These two "features" are connected, so I'll put here some common technical
33 elaboration. The debate on "dups" one mostly concentrated around flat vs
34 categorised namespace or, on the user level, search vs browse paradigm.
35 Following the "Gentoo is about choice" line of thought I see only one
36 possible decision here, - to provide both features :). The solution may be
37 simple - treat the "category path" as a part of package name. For the search
38 purposes make the search routines a bit more intelligent, making it to accept
39 request for searches in "basename" only or any other part of the
40 categorization.
42 What should happen when the dups are requested or encountered?
43 If during search - report all matches (just as it does it now anyway),
44 if during action request (e.g. emerge or unmerge), stop and ask for
45 clarification.
47 One other argument for abandoning categorization was that it is hard to select
48 "one true" category for a package in many cases as it really might belong to
49 multiple. This immediately suggests the following:
51 3. Add search keywords (or some other tags) to packages.
52 I believe this was considered for the extended metadata format in the future
53 and even mentioned not so long ago (although I don't remember where and when
54 and I don't see relevant GLEP, should I file one?). I am bringing this up
55 largerly to complete "the picture" started in pp 1 and 2.
57 Taken together these three "enhancements" should make it possible to maintain
58 both search and browsing ability for portage database even as it continues to
59 grow.
62 Now last but not least for this email
64 4. Partial portage checkout.
65 This also was already touted. One of the variants was even recently proposed
66 right here, in this list. I am mentioning this mostly to reiterate and remind
67 other possible approaches to this.
69 4.1 "Thematic" checkouts.
70 Goes along the (proposed) work on "partitioning" the tree for particular
71 tasks. The "corporate" theme was mentioned not so long ago (something along
72 these lines had a "server" tag in discussions happened about 6-12 month ago I
73 believe). As long as there is work on supporting a thematic tree "partition"
74 and as long as it is in a reasonablt consistent state it should be possible
75 to provide such thematic checkout functionality
77 4.2 "Stability" checkouts.
78 Similar partitioning, but based aroung the presumed stability of packages.
79 This may follow the present arch/~arch divide or more levels as/if we
80 introduce them. Apparently this should be inclusive, i.e. poeple who want
81 "testing" stuff are goind\g to get "stable" as well.
83 These two seem like a lot of work, but in reality major part of this work is
84 done in package maintainership and other regular activity (that would
85 otherwise happen anyway). portage-ng would basically just need to provide
86 some support functionality for that.
88 On the contrary the next one (the one that was proposed not so long ago) seems
89 to require not as trivial extension to portage, as it would need some
90 nontrivial infrastructure support.
92 4.3 "On demand" checkouts.
93 I cannot find it right now, but I remember this was proposed on this list just
94 a bit over a week ago. Or was it on -dev? Anyway, the idea is to checkout
95 some "base" collection by default and then do checkouts of more stuff as user
96 requestes (may be indirectly as dependencies).
98 Oh, and we might consider getting all three (or more if they are requested) of
99 them, they don't seem to be mutually exclusive :).
101 George
104 --
105 gentoo-portage-dev@g.o mailing list


Subject Author
Re: [gentoo-portage-dev] few more portage-ng "feature proposals" Pieter Van den Abeele <pvdabeel@g.o>