I am a sucker for a good editor. I like atom. Don’t yell at me. Its pretty good for my use cases. It has lots of nice extensions I can and have used. Atom is not without its dependencies though. Installing it, which should be relatively simple, turns out to be … well … interesting.
`[root@centos7build nyble]# rpm -ivh ~/atom.x86_64.rpm
error: Failed dependencies:
libXss.so.1()(64bit) is needed by atom-1.26.0-0.1.x86_64
`
In searching the interwebs for what Xss is, I happened across this little tidbit
While you might think, hey great, he found something that worked, let me briefly describe this machine to you, so we can decide if it is really “great”. This is a HVM, running KVM, with no display. It is a build machine I set up for building my NyBLE stack. Its running locally on one of my 10 year old boxen. I wanted to put atom on there, as it is on my gigabit lan, and I don’t mind remote X here at home. The editor performs nicely from my laptop. That is, in order to use a text editor, I had to install a screensaver on a headless VM. Ok, this isn’t quite the worst of it. While I was researching what the minimal installation of CentOS I could get away with and have something fully functional for my purposes, I started looking into the package groupings. Take the “Minimal Install” grouping, which I would assume, would install the bare minimum I need to get an operational system.
`[root@centos7build ~]# yum group info "Minimal Install"
...
Environment Group: Minimal Install
Environment-Id: minimal
Description: Basic functionality.
Mandatory Groups:
+core
Optional Groups:
+debugging
`
Ok, it is build upon the core group. Lets look at that.
`[root@centos7build ~]# yum group info "core"
Loaded plugins: fastestmirror
...
Group: Core
Group-Id: core
Description: Smallest possible installation.
Mandatory Packages:
audit
basesystem
bash
+btrfs-progs
coreutils
cronie
curl
dhclient
e2fsprogs
filesystem
+firewalld
glibc
hostname
initscripts
iproute
iprutils
iptables
iputils
irqbalance
kbd
kexec-tools
less
man-db
ncurses
openssh-clients
openssh-server
parted
passwd
plymouth
policycoreutils
procps-ng
rootfiles
rpm
rsyslog
selinux-policy-targeted
setup
shadow-utils
sudo
systemd
tar
+tuned
util-linux
vim-minimal
xfsprogs
yum
Default Packages:
+NetworkManager
+NetworkManager-team
+NetworkManager-tui
+NetworkManager-wifi
+aic94xx-firmware
+alsa-firmware
biosdevname
dracut-config-rescue
+ivtv-firmware
+iwl100-firmware
+iwl1000-firmware
+iwl105-firmware
+iwl135-firmware
+iwl2000-firmware
+iwl2030-firmware
+iwl3160-firmware
+iwl3945-firmware
+iwl4965-firmware
+iwl5000-firmware
+iwl5150-firmware
+iwl6000-firmware
+iwl6000g2a-firmware
+iwl6000g2b-firmware
+iwl6050-firmware
+iwl7260-firmware
+iwl7265-firmware
kernel-tools
libsysfs
linux-firmware
microcode_ctl
+postfix
Optional Packages:
dracut-config-generic
dracut-fips
dracut-fips-aesni
dracut-network
initial-setup
openssh-keycat
rdma-core
selinux-policy-mls
tboot
`
Look at all that nice firmware I don’t need/want. As part of core. Which is part of “Minimal Install”. And NetworkManager. And postfix. The problem is, when you install other packages, they will pull often large additional swaths of dependencies in to provide a library or a function which isn’t really used or needed. Like the libXss with atom. What I want, as a user, is to be able to build/install a minimal sized effectively appliance OS. I don’t want/need massive dependency radii. In fact, such a thing is an anti-pattern. It is the opposite of what I need. Assume I am building minimal sized installations as appliances I can deploy quickly and easily. Do I really need LaTeX in, because of an obscure tertiary or worse dependency graph? No. And, to make matters worse, if you try to excise the unneeded packages, you invariably risk the integrity of the package set you are attempting to install. As that dependency graph is unforgiving. If I were a conspiracy theorist (I am not), I might follow a flight of fancy over distro lockin with extended dependency radii. I am, or like to think of myself as, pragmatic, which means I try not to let things like this get in the way of doing what I need to get done. And please understand, these dependency radii are inhibitors, barriers to be overcome in many cases. They aren’t helpful. I don’t see distros adding much value beyond bug databases and some packaging/tooling. When the latter gets in the way of the former, I’ll do what I can to contain the damage. I know some people are as wedded to their distros as others are to OSes. Distros, OSes, etc. are details of an instance. Not the purpose of the instance. They are tools to be used, changed when they don’t work for something that does work. No one tool is perfect, no one distro, OS, kernel, toolchain is beyond question. This is one of the reasons I question the longevity of distros that attempt to enforce their world view on wide package radii. There is a long tail of users for everything, and the ardent defenders of a particular way of thinking will defend it to the last developer. Even as the world moves on and leaves them behind. Lets encourage the distro people to rethink what it is they deliver. So minimal is really minimal. There is far more value in that, than in trying to tie everything through package management and package dependency graphs that thwart peoples attempts to reduce footprint and increase efficiency.