[gentoo-dev] Re: Stricter --newuse settings

[Duncan]

"Diego 'Flameeyes' =?iso-8859-1?q?Petten=F2?=" <flameeyes@g.o>
posted 200611281926.38355@××××××××××××××××××××××××××××××.org, excerpted
below, on  Tue, 28 Nov 2006 19:26:28 +0100:

> On Tuesday 28 November 2006 18:40, Caleb Cushing wrote:
>> I know that newuse is stricter now. but do my packages really have to
>> want to rebuild because a flag was hard masked. e.g. arts when I had
>> -arts in my make.conf already? seems like it's a little too strict.

> This is not because of a use.mask over a flag, I'm afraid. I've removed
> some arts useflags in the past days, a they are currently showing
> everywhere there's a kde eclass uasage, this is suboptimal as most of the
> times arts is not actually needed there.
>
> When a flag is removed from a package it might be the same as having it
> disabled or enabled, it depends, so --newuse does its job by rebuilding
> the package.
>
> Indeed even when a package _requires_ arts, I remove the useflag and force
> arts on.

Thanks for your hard work, Diego (and everyone else too, but I'm a KDE
user so appreciate this in particular). It's appreciated and makes for a
better Gentoo, altho I too have been known to gripe under my breath at
whatever USE flag removal forcing --newuser rebuild, when I as a /human/
know it's not needed.

The question that has occurred to me is if there might be some way to
implement a package.newusemask or the like.  I haven't hashed out the
details, therefore no bug filed, but since the topic is raised...  The
idea is some way, here suggested as a package.newsusemask file, for a
sysadmin to in effect say "OK, I've seen that --newuse change and for
whatever reason, don't want to bother with that particular package right
now, so ignore that change for now, as if it hadn't happened."  With such
an implementation in place, an entry such as what might be added to
package.use could now be added to package.newusemask, and portage would
then ignore changes to that USE dependency for that atom.

So, portage devs, is this reasonable, or entirely unworkable for some
reason that hasn't occurred to me?  If it's reasonable, are we looking at a
small change or a big change, and at what relative priority and timeframe
is implementation possible/likely?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list