Sent this to -portage-dev [1] last month with little feedback on the idea itself, so starting another try.
From: Marius Mauch <[EMAIL PROTECTED]> To: gentoo-portage-dev@lists.gentoo.org Reply-To: gentoo-portage-dev@lists.gentoo.org 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.
signature.asc
Description: PGP signature
