Re: [gentoo-portage-dev] [RFC] making the tree depend on portage
Jason Stubbs wrote: On Tuesday 20 December 2005 21:42, Francesco Riosa wrote: Whenever we want/need to make structural changes to the tree that are going to break backwards compability we have a serious problem [...] Just throwing random thoughts here, but Would a rescue-portage help on this ? It's easy enough to install portage from sources (for the time being) that I'd say it's not necessary at this stage. A HOWTO on the matter would be much quicker and easier to maintain while it remains viable. (-: great :-) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] making the tree depend on portage
On Tuesday 20 December 2005 23:15, Jason Stubbs wrote: On Tuesday 20 December 2005 01:49, Marius Mauch wrote: Also not talking about implementation details yet, just after comments about the general idea of forced portage updates. I gave it a go anyway... ;) Also needed: Index: portage.py === --- portage.py (revision 2414) +++ portage.py (working copy) @@ -6742,7 +6742,7 @@ mtimedbkeys=[ updates, info, version, starttime, -resume, ldpath +resume, ldpath, last_system_check ] mtimedbfile=root+var/cache/edb/mtimedb try: -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
[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 -- 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
