Gentoo Archives: gentoo-dev

From: Marius Mauch <genone@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] making the tree depend on portage
Date: Wed, 25 Jan 2006 15:58:51
1 Sent this to -portage-dev [1] last month with little feedback on the
2 idea itself, so starting another try.
4 From: Marius Mauch <genone@g.o>
5 To: gentoo-portage-dev@l.g.o
6 Reply-To: gentoo-portage-dev@l.g.o
7 Subject: Re: [gentoo-portage-dev] [RFC] making the tree depend on
8 portage
10 Ok, the subject might be confusing, so let me explain this a bit:
12 Whenever we want/need to make structural changes to the tree that are
13 going to break backwards compability we have a serious problem (see
14 GLEP 44 in case you don't know about it). To reduce the impact of that
15 problem I've got the idea to make the tree itself (so not any
16 particular ebuild or profile) DEPEND on a minimal portage version,
17 which the users would be forced to upgrade to (maybe with an override)
18 before they can do anything else (with the exception of --sync).
19 Manifest2 is one example for such a situation, another one is the
20 request to not create manifest entries for ChangeLog and metadata.xml
21 anymore (needs >= on user side).
22 Don't really like this idea myself, but somthing needs to be done to at
23 least reduce the problem, having to wait years for old portage versions
24 to (almost) vanish can't be a permanent solution.
26 Also not talking about implementation details yet, just after comments
27 about the general idea of forced portage updates.
29 And just in case anybody wonders: this cannot be fixed with EAPI or
30 adding a portage dep on packages as those only take effect when the
31 ebuild is already parsed while the mentioned problems occur much
32 earlier.
34 Marius
36 [1]
38 --
39 Public Key at
41 In the beginning, there was nothing. And God said, 'Let there be
42 Light.' And there was still nothing, but you could see a bit better.


File name MIME type
signature.asc application/pgp-signature