Next tides of users slowly notice that a number of unneeded files is installed on their systems. They enumerate systemd unit files, logrotate files, take their pitchforks and start their cruciates against Gentoo developers wasting their precious disk space.
Let me tell you a story. The story starts when Uncle Scarabeus wants to add bash-completion support into libreoffice ebuild. He considers this a minor addon, not worth the half a day necessary to rebuild libreoffice, so he doesn’t revbump it. He simply assumes the change will be propagated nicely when users upgrade to the next version.
Of course, some users will already come shouting here: that’s against the policy!
Yes, indeed it is. But is it worth the hassle? Should all libreoffice users be forced to rebuild that huge package just to get a single tiny file installed? He could wait and add that along with the next version. Well, if he wouldn’t forget about it.
But that’s not really important part here. Because, to his surprise, many users have actually noticed the change. That’s because the use of bash-completion.eclass has caused the ebuild to have IUSE=bash-completion; and many of the --newuse Portage option users have rebuilt the package. A few others, like me, just stopped using that option.
That’s when the discussion started. We — the few devs actually caring about discussing — decided that it is quite pointless to control installing tiny files through USEflags. Of course, the libreoffice is an elephant-case here but so-called regular packages aren’t much better here. Is there really a reason to rebuild even 10 C files when the only thing going to change is a single, tiny text file being installed or not?
Another solution is to split those files into separate ebuilds. But that’s usually inconvenient both for users and devs. Users have to notice that they need to emerge an additional package to get the particular file installed, and devs need to maintain that additional package. That starts to become really ridiculous with files like systemd units which are often generated during build-time and store installation paths.
So what to use? INSTALL_MASK, obviously. It’s an ancient Portage magic which allows you to control which files will be punted from installed files. You can use app-portage/install-mask to quickly set it for the files you don’t want. It’s as simple as:
# install-mask -a systemd logrotate
I think it all comes down to missing (?) feature in portage – reinstalling package without recompilation.
Some use case: once I hadn’t “doc” use-flag in make.conf, but often I wanted(or needed) to read the documentation, so I had to reemerge package, with “doc” use-flag enabled. Unfortunately, some of the packages had long compile-time and had cpu-intensive compilation (like blas-atlas), and recompiling it just to get documentation was painful, so I had to choose – recompile or give up and search for documentation online.
Now I have “doc” use flag in make.conf, but it’s not perfect – I don’t need documentation for every package, yet I’m saving time recompiling them when I really would need it. If portage had utility like “emerge-doc”, that would emerge just documentation for given package, it would save me some time, and made portage even more awesome :D
The same goes for “bash-completion”, “systemd”, “configuration” (afaik there’s “emerge –config”, but it configures package, it doesn’t install configuration files) etc.
I think the doc use flag is generally used for documentation that gets generated when compiling a package.
Not for every project, documentation is generated during compilation, more often it’s either generated (or preprocessed) after (successful :( ) compilation (using separate tool, like doxygen or javadoc), or not generated at all (it’s static).
“doc” useflag enables 2 steps – “building” documentation (e.g. invoking “make doc”) and installing “documentation” (e.g. invoking “make install-doc”) :P
If “building” documentation requires compilation of package, portage should do it, but if not, doing it is pointless.
It would be nice if packages could define a list of suggested masks too.
That way, you can both have package-provided USE-like flags, and you can make the same without even updating the ebuild because those are generic.
I’d say that it could be even possible to add a new mask to an already-installed package because it only involves removing files from disk and from the list of installed files.
And you could change (add/remove) without rebuilding the packages by building a full binary archive for every package.
Well, I think per-package
INSTALL_MASKcould be set using/etc/portage/envbut that’s usually much more work.And the second paragraph describes exactly why I did go the INSTALL_MASK way.
Nice tip, already implemented this for some common doc files (those that are installed even without the doc USE flag).
To view the most common ones do:
ls -R1 /usr/share/doc | grep bz2 | sort | uniq -c | sort | tail -n 10Almost correct, but it should be:
ls -R1 /usr/share/doc | grep bz2 | sort | uniq -c | sort -n | tail -n 10
I really don’t understand why people get so upset about these tiny files getting installed. Most of the time they’re so small that they end up being packed into the free space of already existing blocks anyways.
Usually that’s something like . A more serious issue are embedded systems but those usually need
INSTALL_MASKanyway due to docfiles and so on.I saw those flags go, I thought to myself yup, good riddance, and now it seems even more sensible. Good job.