Gentoo Archives: gentoo-dev

From: "Róbert Čerňanský" <openhs@×××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Things one could be upset about
Date: Sun, 25 Jan 2015 13:28:01
Message-Id: 20150125142750.3d68bc47@amit.mysel
In Reply to: [gentoo-dev] Re: Things one could be upset about by Duncan <1i5t5.duncan@cox.net>
1 On Sun, 25 Jan 2015 04:29:43 +0000 (UTC)
2 Duncan <1i5t5.duncan@×××.net> wrote:
3
4 > Alexey Mishustin posted on Sat, 24 Jan 2015 21:54:06 +0400 as
5 > excerpted:
6 >
7 > > 2015-01-20 14:42 GMT+04:00 Róbert Èeròanský <openhs@×××××××××.com>:
8 > >>
9 > >> I somehow thought that edit the overgrowing package.use
10 > >> file upon each emerge world annoys anyone the same as me.
11 > >
12 > > But for me this is one of the most useful and convenient options in
13 > > Gentoo. Yes, I do edit package.use almost every emerge world. And I
14 > > like to do it. And I don't want to delegate this right to any
15 > > program - portage, or any other.
16 >
17 > Agreed that I don't want to (and won't) delegate that decision, but
18 > almost every emerge world? Not here. So ???
19 >
20 > I do edit package.use (or my global USE flags) occasionally, but not
21 > as often as the above implies. What might I be doing different?
22 > Well, here's what I do:
23 >
24 > 1) I try to sync and update deep newuse @world once a week, tho
25 > sometimes it's every two weeks (but sometimes it's daily). I suppose
26 > if people only get to it every couple months, they'll have more
27 [...]
28 > So maybe it's simply that I update frequently enough, tho I /do/ run
29 > ~arch as well, which changes much faster than stable, and I even run
30
31 More frequent updates is most likely the reason that you do not have
32 to edit use flags every time. Running testing perhaps does not
33 increase the editing frequency because dependency changes are the same
34 regardles of how many bumps a package has. For example in testing
35 you'll get following updates of package foo: foo-1.1, ~foo-1.2,
36 ~foo-1.3, foo-1.4. In stable, I would get: foo-1.1, foo-1.4. If
37 dependency changes in 1.3, both of us could have to edit USE flags
38 once.
39
40 I update every 2-4 months (only GLSAs in between) therefore my
41 experience is that I have to edit it every time (not for GLSAs of
42 course).
43
44 > 2) My global USE= starts with -*. I got tired of worrying about what
45 [...]
46 > 3) I don't normally distinguish between local and global USE flags.
47 > I normally treat them all as global and set them globally in my
48 > make.conf use file[1]. When I encounter a new USE flag, because of
49 > the -* in USE, it's off by default. If I decide I want it off, no
50 > problem, it's off. If I decide I want it on, I run an equery hasuse
51 > <flag> to see if any other package uses it. If nothing else uses it,
52 [...]
53 > Similarly, if I encounter a new USE flag that's on already, obviously
54 > some other package I use is already using it and the entry is in my
55 > use file or it wouldn't be on already, due to the -* in that use
56 > file. That's a strong hint what I'm likely to want the default to
57 > be. If I decide I want it off anyway, I run an equery hasuse <flag>
58 [...]
59 > So for all flags, if I want the default off, due to the -* in my use
60 > file, it's off. If I want the default on, it's in my use file,
61 > turning it on.
62 >
63 > 4) The result is that my package.use files contain ONLY non-default
64 > entries.
65
66 More or less same here, except -* as the default. I trust developers
67 that they are choosing wisely in profile and ebuilds. ;-) If not, I
68 see it in emerge -av output anyway and can disable/enable particular
69 flag. But generally I have vast majority of flags in make.conf and
70 exceptions in package.use.
71
72 > When I set such an entry, I prefix a comment line with the date and
73 > an explanation of WHY the entry needs to be there, different from my
74 > normal default settings. Sometimes, it's due to a bug, and a couple
75 > versions later I can go thru and test with that entry commented, to
76 > see if the bug is fixed, yet. Other times it's due to a use-dep from
77 > some other package I have installed. Both qt and kde tend to have
78
79 This where we get to the point. If you set USE flag because of a bug
80 or because of dependency it is not because you *want to* but because
81 you *have to* (or portage *needs to*). Therefore you need to add a
82 comment WHY you did it.
83
84 For example I have -doc in make.conf because I do *not want* docs
85 globally. But I have 'dev-lang/python doc' in package.use because I
86 develop in Python and *want* the documentation for it. Such entry
87 does not need a comment, because I simply know what I want.
88
89 Another example. I have -python globally and have been using
90 app-mobilephone/gammu. Now I want to emerge app-mobilephone/wammu.
91 But it needs +python for gammu, so I *have to* set
92 'app-mobilephone/gammu python' in package.use. In this case I also
93 add a comment which explains the reason because it is not what *I
94 want* it is what *portage needs*. Once this dependency is gone
95 (either because wammu stops requiring it or I unmerge it) it is on me
96 to detect it and remove the entry. So effectively I manage portage's
97 stuff in my configuration file.
98
99 > Regardless of why it's there, however, because only non-default
100 > entries are in package.use, they're the obvious exception.
101
102 You somehow do not distinguish between those two types of exceptions
103 explained in examples above.
104
105 > And as exceptions, they don't tend to change that often. =:^)
106 > Generally,
107
108 They might change as often as package dependencies and for those we
109 have --depclean. For use dependencies we have to go by hand through
110 package.use and check each entry if it is still needed or let have
111 bunch of unnecessary crap installed on our systems. This is not very
112 good user (or admin) experience.
113
114 > 5) Because all my USE flag defaults are set in my global use file,
115 > and package.use contains only exceptions, organizing my package.use
116 > files by use flag makes more sense than the usual by-package
117 [...]
118 > 0-bindist
119 > 0-curl
120 > 0-custom-cflags
121 > ...
122 > binary
123 > crypt
124
125 Indeed an interesting organization of package.use.
126
127 Robert
128
129
130 --
131 Róbert Èeròanský
132 E-mail: openhs@×××××××××.com
133 Jabber: hs@××××××.sk

Replies

Subject Author
[gentoo-dev] Re: Things one could be upset about Duncan <1i5t5.duncan@×××.net>