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

[Duncan]

Róbert Čerňanský posted on Sun, 25 Jan 2015 14:27:50 +0100 as excerpted:

> On Sun, 25 Jan 2015 04:29:43 +0000 (UTC)
> Duncan <1i5t5.duncan@×××.net> wrote:
>> [...]
>
> More frequent updates is most likely the reason that you do not have to
> edit use flags every time.

With the information below, seems like it.

> I update every 2-4 months (only GLSAs in between) therefore my
> experience is that I have to edit it every time (not for GLSAs of
> course).

I'd worry about that.

Frankly, I think the GLSAs are often too slow to come out, but I'm 
honestly not sure what could practically be done to fix it.  The problem 
(as I understand/see it) is that by policy the GLSAs don't get released 
until all security-handled archs have stable-keyworded the fixed package-
version, and some of those security-supported archs are underpowered and/
or undermanned and simply take longer than I'd consider ideal to do that 
keywording, even at security-priority.  But the only real and practical 
fix would be either GLSA's per-arch as they stabilize, and accepting that 
such a policy means the slow archs /will/ be sitting there exposed 
without a stabilized fix or GLSA, OR a GLSA-on-first-stable policy, and 
accept that archs behind the first to stable would be getting GLSAs 
suggesting fixed packages that might not actually be tested and 
stabilized for a month on some affected archs.

The result of the current policy is that if you're waiting for the GLSA, 
unless it's _extreme_ priority (heartbleed level), on at least amd64, 
you're very often sitting there exposed for well over a week, and too 
often a month, after the fix is out there, actually installed on /my/ 
systems.  And to me that's a game of Russian Roulette odds that I'm 
simply not willing to play.

If you're going to do security-updates only, at least follow a good 
notification service (LWN's daily security updates notices are a start, 
if you compare against what you have installed on gentoo), and grab the 
corresponding gentoo updates before the GLSAs.  At least then, if it's at 
least high enough priority to hit the news, you'll have it manually 
installed and won't be sitting there with your *** hanging out for weeks 
at a time!

>
>> 2) My global USE= starts with -*.  I got tired of worrying about what
> [...]
> More or less same here, except -* as the default.  I trust developers
> that they are choosing wisely in profile and ebuilds. ;-)

It's not that I don't trust 'em.  I'm running their ebuilds as root, 
after all. =:^)

It's more the certainty of knowing however it's set, I set it that way, 
and other than a flag name change or add/remove, it's going to stay that 
way unless I change it.  Also, figuring out where a tree default comes 
from isn't as easy or intuitive as it might be.  Both the profiles and 
the ebuilds (with eclasses) cascade, and while I agree with doing it that 
way (I was around before cascading profiles and when eclasses were much 
simpler than they are today, and believe me, this way's easier/better!), 
it doesn't make looking up things easier.

FWIW I negate my entire @system set and thus have an empty @system, with 
some otherwise @system packages in @world, and a few simply not installed 
as such, for similar reasons.  I want to control it myself.

Plus, after setting -* in my use file, all the -flag entries in the file 
could go away.  MUCH cleaner USE file now! =:^)  And it turned out there 
actually weren't that many changes after that, because I had negated 
profile or IUSE defaults enough already, with package.use where it 
deviated, that -* ended up being a rather large simplification of the use 
file itself, with few actual flag changes. =:^)

The one thing I /do/ need to be aware of, now, is that I /don't/ 
automatically see IUSE defaults in the various packages.  Thus, on new 
packages or major upgrades that significantly change USE flags, when I'm 
in doubt on a flag, I do occasionally actually check the ebuild, to see 
whether the maintainer considered it important enough to use-default it 
on.

>> When I set such an entry, I prefix a comment line with the date and an
>> explanation of WHY the entry needs to be there, different from my
>> normal default settings.  Sometimes, it's due to a bug, and a couple
>> versions later I can go thru and test with that entry commented, to see
>> if the bug is fixed, yet.  Other times it's due to a use-dep from some
>> other package I have installed.  Both qt and kde tend to have
>
> This where we get to the point.  If you set USE flag because of a bug or
> because of dependency it is not because you *want to* but because you
> *have to* (or portage *needs to*).  Therefore you need to add a comment
> WHY you did it.
>
> For example I have -doc in make.conf because I do *not want* docs
> globally.  But I have 'dev-lang/python doc' in package.use because I
> develop in Python and *want* the documentation for it.  Such entry does
> not need a comment, because I simply know what I want.

My comment for the latter is generally along the lines of "I want docs 
for this", or "docs here are useful".

Here, it's justifying the non-default with documentation.  It doesn't 
matter so much whether it's a non-default I want specifically, or one 
that was forced on me, there's a reason I set my USE flags as I do, and 
deviating from that needs justification, so I provide it... in a way that 
makes sense to me, at least.  I'd not expect those "docs are useful here" 
comments to make much sense to others, as it's begging the question (in 
the legal and original Latin circular reasoning sense).  But it's 
justification for the non-default, to me.

> Another example.  I have -python globally and have been using
> app-mobilephone/gammu.  Now I want to emerge app-mobilephone/wammu. But
> it needs +python for gammu, so I *have to* set 'app-mobilephone/gammu
> python' in package.use.  In this case I also add a comment which
> explains the reason because it is not what *I want* it is what *portage
> needs*.
>
>> Regardless of why it's there, however, because only non-default entries
>> are in package.use, they're the obvious exception.
>
> You somehow do not distinguish between those two types of exceptions
> explained in examples above.

Because to me, it's the exception that matters.  I document it, and when 
the reason goes away, so can the exception, but whether it's an exception 
forced on me by upstream or one I want, like docs for some particular 
package, it's an exception to a rule that's there for a reason, and that 
exception needs documentation.


But bottom line back on the original debate on every-update USE flag 
changes, yeah, if you're updating only every 2-4 months, then yes, I 
could see that being flag changes every update.  Update frequency is the 
(formerly) mystery reason for the difference, at least the main one!

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