A brief and jaundiced history of Unix packaging systems

January 8, 2010

In the beginning (in the days of V7 and BSD Unix), Unix systems came as a great big tarball or the equivalent that included everything and you just unpacked it onto your machine. If there were problems, people passed around new versions of various bits of source in various ways; you got some, you put them on your system, you recompiled things, and so on.

Shortly after Unix vendors started selling Unix, they discovered that they needed some actual mechanism to deliver bugfixes and updates to their customers in some form smaller than an entire OS distribution. This came to be known as 'patches' and vendors built various programs for it. Because this was the old days, there was a very strong desire to make these patches as small as possible.

Shortly after AT&T started selling Unix, they decided that they wanted to make more money by charging extra for various 'optional' bits, like the C compiler or troff. This required a mechanism to split the previously monolithic blob of the OS up into multiple pieces, ie 'packages'. Other Unix vendors soon followed, even if they were selling BSD, especially as Unix systems accreted more and more pieces that fewer and fewer people were interested in.

However peculiar it seems in today's world, Unix vendors never merged their patching systems and their packaging systems, partly because packages were still fairly big and in the late 1980s and early 1990s people still cared a fair bit about updates being small. Significant OS updates (eg going from X.0 to X.1) were delivered as new packages and might well require a system reinstall, but small ones continued to be delivered as patches. Vendors built increasingly complex and baroque systems for doing each job.

Free Unixes and especially Linux distributions started from scratch in the mid to late 1990s in a very different environment, without any of this accreted history. With minimal manpower available, they built packaging systems because they had to and then simply delivered updates by giving people new versions of the entire package (size efficiency be damned). Because updates were delivered as new versions of packages, these packaging systems grew various features like handling package upgrades.

(Disclaimer: jaundiced views of history are not necessarily entirely correct.)

Written on 08 January 2010.
« Interesting things can happen when you scale things up
Patch management is part of package management »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 8 13:48:50 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.