[gentoo-dev] Re: Things one could be upset about

[Duncan]

Róbert Čerňanský posted on Tue, 20 Jan 2015 06:51:01 +0100 as excerpted:

> On Mon, 19 Jan 2015 20:51:31 +0000 Ciaran McCreesh
> <ciaran.mccreesh@××××××××××.com> wrote:
>
>> On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský
>> <openhs@×××××××××.com> wrote:
>> > From my point of view it would do much help if portage resolves USE
>> > dependencies automatically instead of telling the user to change USE
>> > flags manually (I am talking about bug #258371).
>>
>> This is only possible in carefully selected circumstances, and to get
>> it to work more generally would require a lot of hinting from package
>> maintainers.
>
> But portage already knows that.  It tells the user which USE flags needs
> to be changed in order to emerge a package.  It should just go one step
> further - to make the proposed change happen by itself.

Actually, current portage (2.2.15 is what I have installed here ATM) does 
exactly that, making changes to the appropriate package.* files as 
necessary, mediated only by the usual CONFIG_PROTECT variables.

Since /etc/portage is CONFIG_PROTECTed by default, these changes normally 
first appear in that feature's .* files, to be merged by the admin using 
etc_update or whatever, but if you CONFIG_PROTECT_MASK /etc/portage, 
portage will (I believe, I've never been stupid enough to try it) happily 
write those changes without admin mediation.

And a number of users, including me, objected and still don't like that 
feature, tho with the CONFIG_PROTECT mediation it's at least tolerable.  
As others in-thread have stated, we don't believe that's something 
portage should be messing with.

In particular, I have a specific scheme for my package.* directories and 
the files under them, and portage always wants to write the changes to 
the wrong one... based on my experience so far, apparently the last 
existing file in the appropriate package.* directory, when it should go 
in some other file.

Picking an example out of the air, I have USE=pdf set globally, with
USE=-pdf set for specific packages in a file named after the flag (not 
the package it's set for) and to reflect the fact that I'm disabling it:

/etc/portage/package.use/0-pdf

But if portage were to need to set USE=-pdf on another package, instead 
of writing the changes to apply to that file, it would write the changes 
to apply to...

/etc/portage/package.use/zzpkg-ncmpc

... which is there because ncmpc has several very specific USE flags that 
will never apply to anything else and are best grouped together, and 
which shouldn't contain a USE=-pdf setting for ANY package, INCLUDING 
ncmpc, because that's a more generic USE flag, that belongs in the 
previously mentioned /etc/portage/package.use/0-pdf file.

Of course in practice, no automated ruleset is ever going to make sense 
of the way I have things organized, and I don't expect it to.  Which is 
my point.  Portage shouldn't be editing those files AT ALL.  It should 
spit out the suggested change, and let me edit what I, as the *ADMIN*, 
consider the appropriate file to make that change, assuming of course 
that I actually agree with the changed flag in the first place, and don't 
want to make some other adjustment that I consider more appropriate to 
the specific situation.

At least with CONFIG_PROTECT, tho, portage doesn't just edit the file if 
I accidentally hit an enter when I run my usual post-sync
emerge --ask --update --newuse ... @world.  It simply creates a dot-file 
which I have to delete later, after I've decided the appropriate action 
and taken it.  Which is why I characterize it as at least tolerable.  But 
were that feature to have never been merged, I'd be /much/ happier.


Meanwhile, if you're not seeing that feature yet, then you're not running 
current portage, maybe because you're on stale^h^hble portage or 
something.  But it's certainly there, to my unhappiness if toleration 
because at /least/ it obeys CONFIG_PROTECT.

So this subthread could go away... perhaps to be replaced with one 
griping about portage trying to mess with its own config and screwing up 
badly, with only CONFIG_PROTECT stopping it from /really/ screwing up an 
admin's painstaking portage config.

-- 
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