Optional runtime dependencies (or «suggested dependencies») are one of the late problems we’re facing in Gentoo. There’s definitely a need for some standard solution, and it’d be great to put it in the next EAPI. Sadly, there’s no consensus how to solve it.
Moving systemd into /usr — the technical side
Now that I think of it, I really regret I didn’t make systemd ebuild install it to /usr from the very beginning. But the harm has been done already, and I’d like to move it ASAP and that’s why I’d like to sum up problems with that and possible ways of proceeding with it.
The idea
The idea is simple as it is: move systemd install to /usr prefix completely. Right now, there are no technical benefits from keeping it in rootfs. It already depends on libdbus, which is installed in /usr, and I expect more dependencies over time. There’s no reason to move all those packages into rootfs.
Most importantly, the above information allows me to assume that such move won’t hurt our split-/usr users — because they already had to have /usr mounted for systemd to run.
Continue reading “Moving systemd into /usr — the technical side”
Why there’s no IUSE=systemd, logrotate, bash-completion…
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
Cleaning up /boot with eclean-kernel
# make install
sh /usr/src/linux-drm-next/arch/x86/boot/install.sh 3.2.0-rc2-pomiocik+ arch/x86/boot/bzImage \
System.map "/boot"
cat: write error: No space left on device
make[1]: *** [install] Error 1
make: *** [install] Error 2
Ever hit an issue like that when trying to install a new kernel? Ever thought how much you hate manually removing old kernels? Ever forgot to remove modules as well? If you do, then you may be interested in a tiny new tool called eclean-kernel.
In simplest words, eclean-kernel could be called an old kernel harvester. Given a few tiny settings, it finds the kernels installed in the system, chooses ones to remove and removes them along with the modules and sources (if not used by any other kernel).
The usual way of using it is to set it to keep a few newest kernels, and remove all older than them. To do this, you just need to pass the number as --num
. For example:
eclean-kernel -n 3 --ask
will remove all kernels but the newest three, asking before removing each one. For non-interactive use, omit --ask
; you can also use --pretend
for eclean-kernel to list the kernel versions which would be removed.
By default, it preserves all kernels referenced by the bootloader. The --destructive
option can be used to disable that. If it fails to detect the correct bootloader (or multiple bootloaders are installed), --bootloader
option can be used to specify the one to use.
It can also preserve some kinds of kernel files to fit more specific setups. For example, if you’d like to keep old kernel configs, just pass --exclude config
.
And finally, you can avoid having to repeatedly provide the same options by putting them in your ~/.config/eclean-kernel.rc
. An example file could look like:
-n 3 --ask --exclude config
027 umask — a compromise between security and simplicity
Gentoo systems are shipped by default with umask 022
set in /etc/profile
. It is documented there as quite realistic
setting, in contrary to umask 077
which would be more secure
. I personally disagree with this opinion, saying that 022
is basically suitable only for 100% desktop, single user systems. For a more common case of desktops, I’d stick with 027
instead.
What is an umask?
Wikipedia seems to have a pretty detailed explanation of umasks. Keeping it short, umask is a per-session setting which decides what permissions are set on newly-created files. Or, to be more exact, which permissions are removed from those files by default.
The 022
umask means that all users are allowed to read (and execute) files newly-created by the affected user but only the owner will be able to write them. On the contrary, 077
means that noone but the owner is able to read or execute newly-created files.
As the umask setting often involves configuration files as well, setting 022
globally means that other users will be able to read private user configuration files. On the other hand, 077
means that creating files intended for public reuse will always require using chmod
to re-adjust the permissions.
What would 027 change?
The 027
umask setting means that the owning group would be allowed to read the newly-created files as well. This moves the permission granting model a little further from dealing with permission bits and bases it on group ownership.
First of all, we assume that each real user has his/her own, private, default group. All newly-created files — including configuration files — belong to that group. Considering that the only member of the group is user him-/herself, the files are not readable by anyone else.
Secondly, if some files are intended to be used by a specific group of users (and services), such a permission model can be easily achieved using auxiliary groups. For example, I keep the Portage tree owned by myself and the portage
group. This way, I can perform emerge --sync
using my restricted user and the resulting tree can be re-used by Portage when it drops privileges.
The group model has an additional advantage here. If you set the setgid
bit on a directory, all newly-created files inside it will automatically belong to the same group as the parent directory. In other words, after performing:
chown -R :portage /usr/portage find /usr/portage -type d -exec chmod g+s {} + |
all newly-created files inside /usr/portage
will automatically become readable to portage
group.