Re: [gentoo-dev] Paludis and Profiles

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

On Tue, Jun 13, 2006 at 06:28:41PM +0100, Stephen Bennett wrote:
> Brian Harring wrote:
> >The gain of the profile is that you can do a few new tricks for folks 
> >doing boostrapping experiments- why not just introduce an ebuild that 
> >sets up the new profile in a temp overlay?
> 
> No, the gain is that one could sanely run a Paludis-based system without 
> needing an external overlay, and without having to update said overlay 
> whenever the base profiles in the tree change.

Bluntly, why should the tree be modified for a minority?  Being 
generous, lets pretend y'all have 300 users- why should incompatible 
changes be added to the tree (say 300k users) that can bite 299,700 
users in the ass for the benefit of 300 users?  N parent inherited 
profiles *is* a change that can bite users in the ass, and it's not an 
obvious incompatibility unless you know it exists.

Ebuild level incompatibility is there also, and the only way that's 
going to be resolved is by inspection of each ebuild.

Note I said inspection- just the same as loosing the USE flag state 
for when re-executing the env for an unmerge, loosing local non 
exported vars has the same potential for change.

Not opposed to y'all ironing it out in an overlay and proposing the 
switch (with a sane transition plan)- am opposed to the "lets just do 
it and ignore the consequences to the userbase" mentality that such 
requests imply.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]