Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Things one could be upset about
Date: Sun, 25 Jan 2015 04:30:13
Message-Id: pan$5dafe$fe1f3ff4$cf0ecf61$1b5e7071@cox.net
In Reply to: Re: [gentoo-dev] Things one could be upset about by Alexey Mishustin
1 Alexey Mishustin posted on Sat, 24 Jan 2015 21:54:06 +0400 as excerpted:
2
3 > 2015-01-20 14:42 GMT+04:00 Róbert Čerňanský <openhs@×××××××××.com>:
4 >>
5 >> I somehow thought that edit the overgrowing package.use
6 >> file upon each emerge world annoys anyone the same as me.
7 >
8 > But for me this is one of the most useful and convenient options in
9 > Gentoo. Yes, I do edit package.use almost every emerge world. And I like
10 > to do it. And I don't want to delegate this right to any program -
11 > portage, or any other.
12
13 Agreed that I don't want to (and won't) delegate that decision, but
14 almost every emerge world? Not here. So ???
15
16 I do edit package.use (or my global USE flags) occasionally, but not as
17 often as the above implies. What might I be doing different? Well,
18 here's what I do:
19
20 1) I try to sync and update deep newuse @world once a week, tho sometimes
21 it's every two weeks (but sometimes it's daily). I suppose if people
22 only get to it every couple months, they'll have more updates to do, and
23 within that time yes, I guess it's pretty likely they'll have a few USE
24 flag changes to work thru.
25
26 So maybe it's simply that I update frequently enough, tho I /do/ run
27 ~arch as well, which changes much faster than stable, and I even run some
28 packages (mostly kde) from the overlays, before they even enter the main
29 tree, so I'd /think/ every couple months updating stable would be like
30 every week or two updating ~arch.
31
32 2) My global USE= starts with -*. I got tired of worrying about what the
33 profiles set, and what individual package IUSE-defaults were doing, so I
34 simply set -* so everything would default to off like it USED to do,
35 years ago, and I can turn on what I want/need when I decide I want/need
36 it. So if it's on, I turned it on.
37
38 3) I don't normally distinguish between local and global USE flags. I
39 normally treat them all as global and set them globally in my make.conf
40 use file[1]. When I encounter a new USE flag, because of the -* in USE,
41 it's off by default. If I decide I want it off, no problem, it's off.
42 If I decide I want it on, I run an equery hasuse <flag> to see if any
43 other package uses it. If nothing else uses it, I simply set it globally
44 in my use file, turning it on for that package and anything else that
45 might use it in the future. If I want it on for the new package but
46 something else uses it I obviously had it off for it before or it'd
47 already be turned on in the use file, so I decide if I want to change the
48 default to on or not. If so, it goes in the use file. If not, I have to
49 decide if I REALLY want it on for the new package or not, and if so, I
50 set a non-default entry in a package.use file.
51
52 Similarly, if I encounter a new USE flag that's on already, obviously
53 some other package I use is already using it and the entry is in my use
54 file or it wouldn't be on already, due to the -* in that use file.
55 That's a strong hint what I'm likely to want the default to be. If I
56 decide I want it off anyway, I run an equery hasuse <flag> and check how
57 many packages I have with it, and decide what I want the default to be
58 based on that. Only if I want a setting that's different than my
59 default, will I put a new entry in my package.use files.
60
61 So for all flags, if I want the default off, due to the -* in my use
62 file, it's off. If I want the default on, it's in my use file, turning
63 it on.
64
65 4) The result is that my package.use files contain ONLY non-default
66 entries.
67
68 When I set such an entry, I prefix a comment line with the date and an
69 explanation of WHY the entry needs to be there, different from my normal
70 default settings. Sometimes, it's due to a bug, and a couple versions
71 later I can go thru and test with that entry commented, to see if the bug
72 is fixed, yet. Other times it's due to a use-dep from some other package
73 I have installed. Both qt and kde tend to have explicit use-deps for
74 some of their dependencies, and I'll explain that in the comment.
75
76 Regardless of why it's there, however, because only non-default entries
77 are in package.use, they're the obvious exception. And as exceptions,
78 they don't tend to change that often. =:^) Generally, they'll only
79 change with a major version bump -- say for the upcoming kde5[2], which
80 I've already tried a couple times so have some of the flag changes I'll
81 need for it made already. Or sometimes they'll change if I unmerge a
82 package that had a use-dep, and with it removed, I can remove my
83 exception for that and get back to my normal defaults.
84
85 5) Because all my USE flag defaults are set in my global use file, and
86 package.use contains only exceptions, organizing my package.use files by
87 use flag makes more sense than the usual by-package organization. So
88 (with one exception) all my package.use files are named by flag, not by
89 package, with all entries in a file being the same flag, but for
90 different packages.
91
92 Further more, I name the file based on whether I'm turning the flag on or
93 off. In ordered to have all the per-package-turn-offs (where the default
94 is on) sort first, I use a 0-* naming pattern for those. The others, per-
95 package-turnons where the default is off, are simply named after the flag
96 without the 0-*.
97
98 The one exception I mentioned is for the ncmpc package, which has several
99 very unique flags that will only apply to it, so I do keep those flags
100 together and out of my global use file. It's named zzpkg-ncmpc to keep
101 it last in the listing.
102
103 A partial listing, then...
104
105 $ cd /etc/portage/package.use
106 $ ls
107 0-bindist
108 0-curl
109 0-custom-cflags
110 ...
111 binary
112 crypt
113 doc
114 ...
115 zzpkg-ncmpc
116
117 I have bindist turned on by default, with an entry in my global use file,
118 but turn it off in specific cases, so we have 0-bindist. curl is
119 similarly on by default, but it's off for systemd, which uses it for
120 journal-upload, which I don't want/need, thus that file.
121
122 I have binary and crypt and doc off by default (not in my use file,
123 ensured off no matter the profile or package use-default setting by the
124 -* in my global use file), but have them turned on for specific packages,
125 thus those files.
126
127 And I explained zzpkg-ncmpc above...
128
129
130 So for a new installation until my package and USE flag lists settle
131 down, I'd expect frequent changes, and I'd expect a bunch of changes when
132 I install a major version bump of something big like kde5, or for other
133 big changes like when I switched to systemd and changed a bunch of
134 packages and USE flags as a result.
135
136 But other than that, they don't change that much; certainly not almost
137 every update.
138
139 Yes, almost every update there's a handful of packages with new use
140 flags. And I always check them out and decide what I want to do with
141 them. But most of the time, I already have a default entry for the flag
142 in my global use file, and most of the time I want to keep that default,
143 so no changes necessary on my end.
144
145 So what's different between that and whatever others are doing such that
146 they have package.use changes nearly every update? I don't know, but
147 whatever it is, I'm glad I'm doing the above, and it's not so often, here.
148
149 ---
150 Footnotes:
151
152 [1] My make.conf file itself is simply a list of include <file> lines,
153 one for each type of setting. So I have a use file that contains my USE=
154 setting, with a line sourcing it in make.conf, not a USE= line in
155 make.conf itself.
156
157 [2] KDE5. I've actually already tried it a couple times and have many of
158 the USE flag changes for it already made as a result. But kwin was still
159 crashing on my graphics hardware/drivers when I tried, so I didn't get
160 far, and because it's not possible to have both it and kde4 installed at
161 the same time, I had to unmerge it to get back to a working kde4. I
162 should try again one of these days as it has been a few months, and qt5
163 is actually in the tree now altho I don't believe it's unmasked yet, but
164 at least /that/ part should be considerably more stable than it was, when
165 I was having to install it from the qt overlay.
166
167 --
168 Duncan - List replies preferred. No HTML msgs.
169 "Every nonfree program has a lord, a master --
170 and if you use the program, he is your master." Richard Stallman

Replies

Subject Author
Re: [gentoo-dev] Re: Things one could be upset about "Róbert Čerňanský" <openhs@×××××××××.com>