This post is quite long so here are some links to the relevant material:
Introductions
On most modern operating systems there is a package manager that does the following: installs, un-installs, updates, and downgrades packages (software). The names vary by operating system as do the command(s) to invoke the package manager. (For anyone thinking that Mac OS X doesn’t have a package manager: I’m counting the Mac App Store as a package manager since it does the above. It is a smaller subset of packages and they all have to be blessed by Apple but it still performs the functions listed.)
I’ll be writing about YUM and RPM since those are the systems that I know. From conversations I’ve had with people who run Linux versions that use apt, apt-get, or aptitude most of what I’ve written here applies to it as well.
The most used versions of Linux: Ubuntu (Debian) and Red Hat the package managers are written in the Python programming language. The choice of programming language doesn’t really matter; the fact that it is tied to the version of Python installed on the machine is the problem. This brings me to a set of rules on which a better package manager should be based.
The Rules
1. Package managers should never be dependent on the system version of anything.
Perhaps you, dear reader, haven’t had the opportunity to re-install every RPM on a production machine because they were all deleted somehow. I have had that displeasure and it was not a good time. A package manager that becomes broken when the main version of Python on the system is upgraded from Python 2.4 to Python 2.5 or Python 2.6 is completely worthless. A package manager that no longer works if the system’s Python packages become corrupt is worthless.
This is not to say that the package manager versions shouldn’t be tied to a specific OS versions. Having a YUM 5.x for CentOS/RHEL 5.x makes sense. This means that the package manager is completely self sufficient and self contained.
2. Package managers should never be allowed to un-install themselves or their own dependencies.
This goes with rule number 1. The package manager shouldn’t depend on the system version of anything. No package manager should be able to break itself by un-installing its own dependencies e.g., you can use YUM to un-install glibc, a .SO file on which EVERYTHING in Linux depends. This would be fine if you were able to use YUM to install glibc again but you cannot because it depends on glibc to fucking work. The YUM version in RHEL 5 and up include a re-install command. If you’d think it would work in this case, you’d be wrong.
3. Package managers should be able to upgrade you from one version of an operating system to another with minimal downtime and minimal configuration.
Ah the days of CentOS 6’s release! All the awesome new features with a more sane default filesystem: ext4. (I wrote more sane; it’s still not a production file system.) How great and wonderful, we can upgrade CentOS 5 machines to it, right? NOT A FUCKING CHANCE LOSER. The official answer about upgrading between them was: re-install the machine. Wow, what a fantastic idea; just re-install the machine and restore all of its data and all of your customers’/users’ data, they won’t mind at all.
The only time I’ll accept the answer ‘re-install’ is when moving from a 32-bit OS to a 64-bit OS since that is a major ABI change. However, I still think there should be a way to upgrade from a 32-bit OS to a 64-bit OS with minimal downtime and minimal hassle.
Where’s the Code?
This is just my idea for a better package management system that would actually fucking work. I’m extremely hateful towards YUM and RPM because I’ve been burned too many times by just how shitty they both are.
There are no pull requests with this post, there’s no code, and there’s no suggestions for how to implement any of this because trying to change the way a Linux vendor does anything is pointless. Unless, you want to fork the project and spend the rest of your life maintaining it.
If you think it cannot possibly be that bad to change the way a Linux vendor does things: spend a couple days following some sysadmins and software developers on Twitter. You’ll see plenty of people who have tried to add their software to a distro or just update it and are met with constant bureaucracy.
If you write your own software and want to make it available for people to use: You are far better off building OS packages on your own using tools like FPM, or RPM itself and whatever Debian based systems use. You can host your own YUM/APT repo for pretty cheap and there’s 0 bureaucracy with which to deal. Another acceptable method for making your software available would be putting your code up on GitHub and include a Makefile that will build .deb and .rpm packages.
Conclusions
I just want a working package manager that isn’t dependent on system libraries that it can un-install on its own and also be used to upgrade me to a newer version of the operating system I’m running.
Are there things out there like this? Yes. I keep a Joyent SmartMachine around for the times when I need a VPS. It’s fairly cheap, runs SmartOS, and has a production filesystem: ZFS. Upgrading SmartOS from one version to a new one works pretty well. You simply follow Joyent’s documentation. The documentation isn’t updated very often which irritates me but if you check that there is a newer Quarterly release and follow the instructions your machine gets upgraded. SmartOS uses pkgsrc which is available on numerous systems. After logging out and back in your SmartMachine should be in the state that it was. In some cases I’ve had to re-install Python packages I was using but I’m not sure if that is the case for everyone. While SmartOS upgrades seem to work this isn’t a production machine and I don’t use it for anything that would impact users.
Now that I’ve distilled this caremad into more than a thousand words I don’t know why the systems are set up they way they are now. Who thought it would be a good idea for a package manager to be dependent on the installed system software? Who thought it would be a good idea for the package manager to be able to un-install its dependencies? Who thought that making people re-install an OS in order to upgrade to the newest version was a good idea? Why would anyone think that this is a good idea? I’m happy to listen to any of the reasons behind this. If you’d like to discuss further @ reply me on Twitter (@klyntonj). If this is just some remnant of times when hard drive space was a precious commodity or when RAM was scarce; I’d love to see it die.