Brian Harring wrote:
So... short version, introduction of the profile allows for curious users to get bit in the ass by intentional dropping of compatibility (profile level changes are one thing, changing the ebuild standard is another). In light of that, why should it be demoed in the tree where the only use of it is to bootstrap a new installation? Just overlay it, y'all should be maintaining an overlay fixing ebuild incompatibilities anyways.
This I see as a non-argument. We imitate enough of Portage's idiosyncracies to support every ebuild with which we've tested it, so the ebuild format is for all intents and purposes the same. Sure, a few internal variables have different names, but those are the ones that ebuilds generally shouldn't be using, and if there is a legitimate case where they are used, we emulate it. And it would have uses beyond bootstrapping a new installation-- for example, say, running a system exactly as any other profile is used.
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.
-- [email protected] mailing list
