[gentoo-dev] [RFC] making the tree depend on portage

[Marius Mauch]

Sent this to -portage-dev [1] last month with little feedback on the
idea itself, so starting another try.

From: Marius Mauch <genone@g.o>
To: gentoo-portage-dev@l.g.o
Reply-To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [RFC] making the tree depend on
portage

Ok, the subject might be confusing, so let me explain this a bit:

Whenever we want/need to make structural changes to the tree that are
going to break backwards compability we have a serious problem (see
GLEP 44 in case you don't know about it). To reduce the impact of that
problem I've got the idea to make the tree itself (so not any
particular ebuild or profile) DEPEND on a minimal portage version,
which the users would be forced to upgrade to (maybe with an override)
before they can do anything else (with the exception of --sync).
Manifest2 is one example for such a situation, another one is the
request to not create manifest entries for ChangeLog and metadata.xml
anymore (needs >=2.0.51.20 on user side).
Don't really like this idea myself, but somthing needs to be done to at
least reduce the problem, having to wait years for old portage versions
to (almost) vanish can't be a permanent solution.

Also not talking about implementation details yet, just after comments
about the general idea of forced portage updates.

And just in case anybody wonders: this cannot be fixed with EAPI or
adding a portage dep on packages as those only take effect when the
ebuild is already parsed while the mentioned problems occur much
earlier.

Marius

[1] http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1554

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.