Distribution package dependency radii, or why distros may be doomed

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.