On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote:
> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote:
> > As I understood it, they were implemented to reduce the amount of work
> > necessary in maintaining them.  As it was back then, it required changes
> > to an extremely large number of profiles every time a change was made to
> > the default USE flags.

> Just a crazy idea - why not create a package containing some profiles?
> You can use the default profile, and if you want a different profile,
> "emerge portage-profiles" or whatever it is called and use that. I guess
> I've missed something obvious here?

How exactly would updating a ton of profiles, making a tarball of them,
uploading the new tarball, waiting for it to hit the mirrors, then
updating the ebuild in portage be easier to maintain than just
maintaining the profiles directly in the tree?

> >  I honestly don't think it would be a good idea
> > to forget the lessons of the past and start bloating the profiles with
> > tons of "desktop" and "server" profiles, among anything else people
> > would want.  After all, as soon as we did a "desktop" profile, then we
> > would have requests for "gnome" and "kde" sub-profiles.

> which are not much work if kde = desktop -gtk -gnome +kde

Once there is multiple inheritance, I see this being easier.  I still
think it is going to be a waste of time for us to maintain them,
however.  Especially since *NO MEDIA* will be built against *any* of
them except the default.

> > As I stated earlier, it's easier to not provide *any* than to try to
> > provide all of the ones that will inevitably be requested as soon as we
> > start adding them.
> Or provide them in an extra ebuild that throws lots of warnings so that any 
> users that don't read the warnings can be RESOLVED WONTFIXed?

You're more than welcome to do this.  *I* would just WONTFIX it anyway
and not add *any* superfluous profiles just to appease some lazy users.
The current profiles are built to be used *as is* for doing GRP
installations.  If the user doesn't like a flag or two, then they change
it themselves.  We don't need to get into the business of determining
what should and should not be enabled on user's systems because we would
*never* be able to make people happy.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to