> > First and foremost is, will adding this to the tree be used for > > function creep, whereby the next request to add to/alter the portage > > tree is backed up by "Well, the profile change was already added to the > > tree"? I wouldn't want a precedent like this set without the council > > reviewing it. > > I really don't see much of an issue of feature creep. Gentoo/ALT > already has a profile. It isn't like there are changes to the actual > ebuilds themselves.
Actually there are a lot of packages that need portage to work properly. Portage has never been added to DEPEND because portage is expected to "be just there". With a paludis profile added how are we gonna deal with that? - Adding $package to the paludis package.mask? - Creating a $packagemanager virtual and expect every packagemanager to provide all the functions offered by portage? (E.g. having wrapperscripts for several calls.) - Make ebuilds that explicit depend on portage depend on portage by adding sys-apps/portage to (R)DEPEND? -- Christian Hartmann http://www.gentoo.org/~ian/ PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865 Key fingerprint = 4544 EC0C BAE4 216F 5981 7F95 2154 E5EE 692A 4865 -- gentoo-dev@gentoo.org mailing list
