Re: [gentoo-dev] rfc: logrotate and xinetd use flags

[Jeroen Roovers]

On Sun, 24 Apr 2011 16:58:23 -0500
William Hubbs <williamh@g.o> wrote:

> I feel that the current approach (using INSTALL_MASK) to control
> whether these configuration files are installed or not is not well
> documented. We tell people about it on the mailing lists, but I do
> not know of a place where it is documented.

INSTALL_MASK is documented in make.conf(5).

> Also, it seems to be an all or nothing arrangement. If I do not want
> logrotate support, I have to set the INSTALL_MASK then if I decide
> later I want it, I have to unset the INSTALL_MASK and run "emerge -e
> world" to get the files installed.

That sounds like a design decision about your own special Gentoo based
distro - it is the same with most USE flags and with other build time
settings like USE flags.

Usually when you decide to use INSTALL_MASK, it's because you want an
as small as possible system image - you're probably developing an
embedded system with storage constraints. If you're really clever about
that and want to delay the INSTALL_MASK decision, you might as well
`mount --bind' some directory on the development system
to /etc/logrotate.d inside the chroot before you start `emerge world'.

Another option is to plan your distribution even better and set
FEATURES=buildpkg. Then, you can unset INSTALL_MASK in make.conf or on
the command line, and emerge the .tbz2 - no rebuilding needed. Maybe
*this* could be better documented, although it does belong in the tips
and tricks department.

(And if you really want to prevent portage from even putting certain
files in the .tbz2, then use PKG_INSTALL_MASK instead.)

> If we use a "logrotate" or "xinetd" use flag, it gives the users
> better control of which packages have this support, and the --newuse
> option in portage can be used to rebuild only the affected packages.

`ls /etc/logrotate.d' should give a clue in the current situation. :)

> I guess the argument against the use flag was that packages were being
> rebuilt just to install configuration files. I can see how that could
> be a pita for big packages. Did anyone ever bring up using pkg_config
> to un/install these files based on the use flags?

It isn't just that you have to rebuild a large package, perhaps
consuming a lot of time or other resources unrelated to actual storage,
but that a package with a large install image (many megabytes) does not
benefit from a USE flag that controls installing an extra kilobyte
(plus a couple more on a typical filesystem).


     jer