On Mon, 2006-06-12 at 14:15 -0700, Brian Harring wrote: > On Mon, Jun 12, 2006 at 09:58:01PM +0100, Stephen Bennett wrote: > > Many things were discussed in the last round of this thread (Paludis > > and Profiles, in case anyone missed it), and many useful points raised. > > One of these, which seems to have been largely missed in amongst the > > other noise, forms the basis of this proposal. It is in some ways more > > and in some ways less intrusive than the previous proposal, > > and is also completely package-manager-agnostic. > > > > In short, I would like to suggest replacing sys-apps/portage atoms in > > the base and default-linux profiles with virtual/portage, and removing > > the python dependencies from them. For most users this would have an > > effective zero change, since the default provider for virtual/portage > > is sys-apps/portage, and the python dependency will be pulled in by > > Portage when calculating system deps. According to my understanding, > > this should also produce no change when building release media, due to > > both Portage and Python being in packages.build. > > > > The only change introduced by this is that it becomes possible to > > bootstrap a system with a different package manager simply by > > installing it before 'system'. There are a couple more changes needed > > to allow this -- namely that a few system packages have old > > dependencies on >=portage-2.0.49, but these can be resolved seperately. > > Any problems caused by packages depending implicitly upon Python will > > show up only on systems not using Portage, and can be easily fixed with > > the cooperation of package maintainers. > > > > I would like to think that this proposal addresses most of the concerns > > raised in the last thread -- it implies nothing about support for any > > other package manager, and introduces nothing that could cause problems > > for Portage users, while still allowing alternative package managers to > > use the tree without needing Portage installed. > > > > I am also aware that this falls roughly under what the Council was > > asked to discuss in its June meeting, but since that seems to have not > > happened, I'm bringing it up anyway, since I would like to get > > something done here. > > +1, dependant on A) catalyst folk not poking holes in it, B) council > outcome tomorrow (no point in changing it till they've weighed in on > the whole enchilada).
As the "catalyst folk" I can say that it shouldn't affect us in any way. So long as packages.build still has sys-apps/portage, packages has virtual/portage, and virtuals has sys-apps/portage as the default for the virtual, it won't affect us. My only request is that this work gets held off on until after we make our 2006.1 snapshot, to reduce the possibility of us having to hunt down possibly hundreds of potential problems in release-building. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
