1 |
William Hubbs posted on Sun, 24 Apr 2011 16:58:23 -0500 as excerpted: |
2 |
|
3 |
> I feel that the current approach (using INSTALL_MASK) to control whether |
4 |
> these configuration files are installed or not is not well documented. |
5 |
> We tell people about it on the mailing lists, but I do not know of a |
6 |
> place where it is documented. |
7 |
|
8 |
It's documented in the documentation, of course. =:^) |
9 |
|
10 |
From the make.conf (5) manpage: |
11 |
|
12 |
INSTALL_MASK = [space delimited list of file names] |
13 |
Use this variable if you want to selectively prevent certain files |
14 |
from being copied into your file system tree. This does not work on |
15 |
symlinks, but only on actual files. Useful if you wish to filter |
16 |
out files like HACKING.gz and TODO.gz. The INSTALL_MASK is processed |
17 |
just before a package is merged. Also supported is a |
18 |
PKG_INSTALL_MASK variable that behaves exactly like INSTALL_MASK |
19 |
except that it is processed just before creation of a binary package. |
20 |
|
21 |
But I agree that isn't as well documented as it might be, despite the |
22 |
manpage documentation. Having it in the handbook's working with portage |
23 |
section would certainly add to its visibility. But I'm not sure that |
24 |
section, despite being dedicated to portage, is intended to be an |
25 |
exhaustive examination of the available settings. I believe it's entirely |
26 |
appropriate to only have that in the manpage, as arguably, people to whom |
27 |
the near-first thought when looking for such a feature is NOT to go see |
28 |
what the manpage has to say about it, perhaps shouldn't be messing with |
29 |
the feature in the first place. |
30 |
|
31 |
IOW, if it weren't in the manpage, I'd say that's a serious bug, the |
32 |
manpage needs fixed. Since it /is/ in the manpage, and Gentoo's manpages |
33 |
are arguably much more accessible than most, additional documentation |
34 |
would be nice, but is arguably low priority TRIVIAL/ENHANCEMENT level |
35 |
stuff. |
36 |
|
37 |
> Also, it seems to be an all or nothing arrangement. If I do not want |
38 |
> logrotate support, I have to set the INSTALL_MASK then if I decide later |
39 |
> I want it, I have to unset the INSTALL_MASK and run "emerge -e world" to |
40 |
> get the files installed. |
41 |
|
42 |
That's not really the case, either. It's certainly possible to add |
43 |
absolute-path-specified names to INSTALL_MASK, and I've done just that in |
44 |
the past, tho I'm not doing so ATM. |
45 |
|
46 |
It's also worth noting the /etc/portage/package.env file and /etc/portage/ |
47 |
env/ subdirs as covered in the portage (5) manpage. Either of these |
48 |
methods can be used to set package-specific stuff like INSTALL_MASK, if |
49 |
the user doesn't want to make it global. And the env/category/pkg feature |
50 |
can even be used for such shell logic as... |
51 |
|
52 |
CFLAGS=${CFLAGS/ -combine/} |
53 |
|
54 |
... which I routinely depend on for a number of packages as -combine is in |
55 |
my global CFLAGS (but not CXXFLAGS). |
56 |
|
57 |
It's thus possible to use either absolute paths in the global INSTALL_MASK |
58 |
settings, or package-specific setting via two different methods, to |
59 |
control the installation of specific files. And the documentation is |
60 |
there, in the usual and customary place one would expect to find it on a |
61 |
*ix system, the manpages. |
62 |
|
63 |
I honestly don't see how a USE flag helps. Yeah, it rubs the user's nose |
64 |
in it a bit more directly, but the users that really care either already |
65 |
know or can find out pretty fast when they need to, how to address the |
66 |
problem on their own systems, and for those that don't, it's yet more USE |
67 |
flag noise to mask the important stuff. Plus, any USE flag added to a |
68 |
package is yet another bit of package maintenance for the gentoo |
69 |
maintainer to keep up on. I simply don't see how the limited benefit can |
70 |
be considered worth the hassle, when both as explained here and as |
71 |
documented, the control is already there for those that actually care |
72 |
about it. |
73 |
|
74 |
-- |
75 |
Duncan - List replies preferred. No HTML msgs. |
76 |
"Every nonfree program has a lord, a master -- |
77 |
and if you use the program, he is your master." Richard Stallman |