Gentoo Archives: gentoo-project

From: Richard Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Re: [gentoo-dev] Re: The KDE overlay moves forward
Date: Wed, 19 Mar 2008 14:46:35
1 Moving this to -project due to topic drift...
3 Steve Long wrote:
4 > Wulf C. Krueger wrote:
5 >> Most of us who are working on the overlay have been using alternative
6 >> package managers (PM) for quite some time now. Thus, the idea arose to go
7 >> a step further and actually make good use of the capabilities they offer
8 >> us.
9 >>
10 > Makes sense; after all you can do whatever you want in an overlay without
11 > concern for how it will affect anyone else.
12 >
14 I wonder if there would be benefits into making gentoo more of a
15 meta-distribution along these lines. Instead of having one definitive
16 portage tree with some experimental overlays, you'd instead have a
17 couple of branches:
19 1. A core portage tree. This would contain at least one package
20 manager and key system dependencies. Any could be overridden by an
21 experimental overlay, but the general intention would be for most
22 ordinary users to use the core tree for the key dependencies like
23 gcc/glibc/baselayout/etc. This will avoid major dependency issues if
24 everybody wants to demand their favorite versions of these kinds of
25 packages which are often unslotted.
27 2. A repository manager GUI that lets users choose any number of
28 application repositories. Said repositories are allowed to collide, and
29 users can select what priority the package manager should give to each
30 in the event of collision (priorities set both at an overall level and
31 per-package/category/etc).
33 3. Gentoo would be free to endorse particular repositories, and
34 possibly manage some of them as well. A default configuration would
35 give new users the sort of experience they'd expect to get by default.
36 Anybody could freely set up a repository with nothing more than an rsync
37 server, although to get linked by Gentoo there might be some minimal QA
38 standards. There could also be multiple tiers of endorsement - from
39 "somewhat unlikely to outright rootkit your box" to "you should pay
40 these guys for this level of quality". There could be license
41 restrictions on endorsed repositories as well.
43 This would offer more user choice, and user involvement, since the
44 various repositories could have varying requirements for participation.
45 Users could potentially fork any part of the distro and still benefit
46 from the rest as well, with everybody benefiting from the resulting
47 sharing. The downside might be division of effort and less unification
48 (many packages could end up having mutally-exclusive requirements such
49 as specific package managers that implement particular EAPIs, etc).
51 This isn't really anything that requires any kind of action - but just
52 food for thought that I figured I'd toss out there.
53 --
54 gentoo-project@l.g.o mailing list