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.dun...@cox.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
