On Sun, 25 Jan 2015 04:29:43 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> wrote:
> Alexey Mishustin posted on Sat, 24 Jan 2015 21:54:06 +0400 as > excerpted: > > > 2015-01-20 14:42 GMT+04:00 Róbert Čerňanský <ope...@tightmail.com>: > >> > >> I somehow thought that edit the overgrowing package.use > >> file upon each emerge world annoys anyone the same as me. > > > > But for me this is one of the most useful and convenient options in > > Gentoo. Yes, I do edit package.use almost every emerge world. And I > > like to do it. And I don't want to delegate this right to any > > program - portage, or any other. > > Agreed that I don't want to (and won't) delegate that decision, but > almost every emerge world? Not here. So ??? > > I do edit package.use (or my global USE flags) occasionally, but not > as often as the above implies. What might I be doing different? > Well, here's what I do: > > 1) I try to sync and update deep newuse @world once a week, tho > sometimes it's every two weeks (but sometimes it's daily). I suppose > if people only get to it every couple months, they'll have more [...] > So maybe it's simply that I update frequently enough, tho I /do/ run > ~arch as well, which changes much faster than stable, and I even run More frequent updates is most likely the reason that you do not have to edit use flags every time. Running testing perhaps does not increase the editing frequency because dependency changes are the same regardles of how many bumps a package has. For example in testing you'll get following updates of package foo: foo-1.1, ~foo-1.2, ~foo-1.3, foo-1.4. In stable, I would get: foo-1.1, foo-1.4. If dependency changes in 1.3, both of us could have to edit USE flags once. 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). > 2) My global USE= starts with -*. I got tired of worrying about what [...] > 3) I don't normally distinguish between local and global USE flags. > I normally treat them all as global and set them globally in my > make.conf use file[1]. When I encounter a new USE flag, because of > the -* in USE, it's off by default. If I decide I want it off, no > problem, it's off. If I decide I want it on, I run an equery hasuse > <flag> to see if any other package uses it. If nothing else uses it, [...] > Similarly, if I encounter a new USE flag that's on already, obviously > some other package I use is already using it and the entry is in my > use file or it wouldn't be on already, due to the -* in that use > file. That's a strong hint what I'm likely to want the default to > be. If I decide I want it off anyway, I run an equery hasuse <flag> [...] > So for all flags, if I want the default off, due to the -* in my use > file, it's off. If I want the default on, it's in my use file, > turning it on. > > 4) The result is that my package.use files contain ONLY non-default > entries. More or less same here, except -* as the default. I trust developers that they are choosing wisely in profile and ebuilds. ;-) If not, I see it in emerge -av output anyway and can disable/enable particular flag. But generally I have vast majority of flags in make.conf and exceptions in package.use. > 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. 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*. Once this dependency is gone (either because wammu stops requiring it or I unmerge it) it is on me to detect it and remove the entry. So effectively I manage portage's stuff in my configuration file. > 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. > And as exceptions, they don't tend to change that often. =:^) > Generally, They might change as often as package dependencies and for those we have --depclean. For use dependencies we have to go by hand through package.use and check each entry if it is still needed or let have bunch of unnecessary crap installed on our systems. This is not very good user (or admin) experience. > 5) Because all my USE flag defaults are set in my global use file, > and package.use contains only exceptions, organizing my package.use > files by use flag makes more sense than the usual by-package [...] > 0-bindist > 0-curl > 0-custom-cflags > ... > binary > crypt Indeed an interesting organization of package.use. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
