The previous post introduced ConnochaetOS, a nice i586 Linux-libre desktop distro which is now dead. Not having received any updates for a long time makes it the ideal target for a little (?) exercise: Updating an old Linux distro which has missed a lot of important changes!
While the previous post showed how to install, update to the most recent (albeit very old) versions available on the repos and change the filesystem to today’s (Arch Linux) layout, we’re going a little bit deeper today by doing some package building and manual updating. The goal is to build newer packages of some important programs which can then be used to further update the system.
It’s only 5 packages today – but I show the package building process in detail here so that even people new to this can easily follow it. Also the next part can then be much shorter.
Package building on Arch-derivatives
With ConnOS being an Arch-derivative, there are fortunately a great many of PKGBUILDS available for most of the programs relevant for us. Most of them can be downloaded from archlinux.org or the Arch User Repository (AUR). When it comes to completely free software replacements (like Linux-libre, a modified kernel without any binary blobs and such) there’s parabolagnulinux.org, another fine source.
With these two alone we already have a great resource which almost completely satisfies our needs. Most of the package build recipes need to be modified for use with ConnOS, primarily because both distributions are not targeted at i586 machines. However this is usually a simple thing to do.
Generally arch=(‘any’) PKGBUILDs will work without modifications if all the dependencies are available on ConnOS. If they are not, it may be desirable to modify them and drop some dependencies which may not be worth the effort. All other recipe files need to be modified to make the i586 architecture available and often to add –host=i586-pc-linux-gnu and –build=i586-pc-linux-gnu to the configure parameters, too.
In many cases this is already all there is to do and package building can begin. The more interesting part is to understand which packages should be updated – and in which order. This is not always clear. And the really tricky part is finding out what to do in case any technology leaps occurred and there isn’t simply a newer version of some package available but a whole new application (which works differently) has replaced it. However this won’t be the case in this part of the updating series.
But enough of the theoretical talk – let’s get started!
Filesystem related updates
I’ll describe what I did to update ConnochaetOS here – including downloading the PKGBUILD files (but not my modifications to them in detail). If you also want to update ConnOS, you can save yourself some time and download my update pack which contains the modified PKGBUILDs I use here.
Alright. We have a system which runs on top of the “new” 3.2 kernel and uses the new filesystem layout now. First I create a new src directory and a subdirectory called iana-etc in my user’s home. Then I use links to go to http://www.archlinux.org/packages/, search for iana-etc and download both files needed to create the package.
Since the version of links available is very old, it doesn’t cope well with compressed files. Both PKGBUILD and newer.patch are gzipped files. And thanks to gzip being an incredibly stupid program (behaving like a Windows application!) we need to add the .gz extension to both files so that we can decompress them…
Then we’re set and can begin building the package with makepkg. If all goes well (and it should) we’re left with a new package called iana-etc-2.30-3-any.pkg.tar.xz. After we become root (with su) we can install it using the pacman -Uf command (“f” is for force and allows pacman to overwrite files currently installed by other packages). Pressing CTRL+D (or typing exit) we leave the root shell since packages should in general not be built with root privileges.
The next package is called filesystem (which could not be installed if we hadn’t adapted our filesystem’s layout to the new one in the previous post). I create a directory for it, download all the required files and decompress them.
While you can at least use wildcards with gunzip, this is not possible when renaming the files. Since there are quite a lot of them in case of this package, the for command comes in handy (for file in *; do mv $file $file.gz; done).
It should actually be adapted to ConnOS, but then again it won’t hurt anybody if some of the installed files say “Arch Linux”, right? Also I simply disabled the manpage part of it – this saves us from building the package asciidoc first and I don’t think that it would be worth our time.
Building and installing (after becoming root) is just the same as above. This package must also be installed with the “f” switch enabled since it needs to override some already existing files which were not part of the old filesystem package. We’ll ignore the warnings and errors right now.
Modernizing a few system components
Next we have to take care of one of the biggest drawbacks with ConnOS: The unavailability of sudo! Creating a new dir for it, downloading the files, renaming and decompressing is nothing new anymore. But since we’re building a package now that contains binaries, the PKGBUILD from Arch needs to be modified. Afterwards the new package can be installed as root (for the last time now). Then only the file /etc/sudoers needs to be changed so that the new user is allowed to use sudo to temporarily gain root privileges.
Now it’s a good idea to update pacman. The most important reason is because the old version ConnOS has cannot understand some important things which many new PKGBUILDs rely on (like e.g. the options variable or the prepare() function). Downloading and building is more or less like before and the modifications include disabling the depends since the PKGBUILD claims pacman to need newer versions of bash, curl and others which is not quite the case. Also some architecture related changes have to be made.
Installing pacman is now a lot more convenient since we can use sudo from now on (no more su!). After upgrading it, the package database must be converted to the new format and the repositories should be updated, too.
The next one is a mere convenience update: Links. The version that comes with ConnOS works well enough but updating it means no more messing with gzipped files. So from my point of view it’s well worth it.
So now ConnOS is in a state where it is much more pleasant to work with. Still this is just one little step compared to all the work that would have to be done to fully update the system.
Describing package building at length took more space than I had anticipated. So the next post will deal with a very important process: Updating the compiler toolchain!