Sudo and package manager – updating an old Linux system pt.2

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.

ConnOS with the “new” kernel

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.

Getting the PKGBUILD with links

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…

Building the package

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.

Forcefully updating the package as root

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.

Links again

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.

Renaming files and package building

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.

Adding the normal user to the sudoers file

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.

Upgrading pacman

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.

Upgrading links

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.

What’s next?

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!

Advertisements

8 thoughts on “Sudo and package manager – updating an old Linux system pt.2

  1. Thanks for this and the previous installment of helpful update information on ConnochaetOS. While I did most of what you instructed, instead of creating symlinks for the old directories (/lib, /bin, and /sbin), I altered .xinitrc to copy all files on startup from the new directories to /usr/lib and /usr/bin, and vice-versa. This means that as the system updates further, /lib, /sbin, and /bin will serve as backups for important files should the /usr tree be corrupted for any reason. Another interesting addenda… I use Siag Office, and discovered that the easiest way to install it was to download the Puppy .pet version of it… Siag-3.5.5.pet from mirror.internode.on.net/pub/puppylinux/pet-packages-lucid/ , rename it to Siag-3.5.5.tar.gz, .and then ./compile (allowing for 1 error), make, make install. Part of the reason I mention this is that it’s likely applicable to more than just that .pet file. Will keep you posted as I try a few other ones.

  2. Hi, Martin! The way you chose with the filesystem layout change is another interesting option. Didn’t think of something like that but I agree with your rationale. Backups of important system files can’t hurt (except on extremely minimal systems with little disk space).

    And thanks for pointing out that easy way of installing SIAG office! I always wanted to try it out but last time I tried something went wrong. I absolutely have to give it another try. Will try out your suggestion this weekend (when I finished the next part of the update posts)!

  3. No troubles! I’ll add that Siag requires your fonts to be updated (installing them via pacman worked for me), and that tsiag – the console spreadsheet – required one library file to be added. What exactly it was escapes me right now, but all I did was google and download it, and rename it from xxxxx.so.2.0.8 to xxxxx.so.2 . Then throw it into the /usr/lib and /lib directories. Even with these 2 minor speedbumps, installing from the .pet file was faster than installing Mowitz, neXtaw, etc. ‘Pathetic Writer’ is funny, but I find it more reliable than Abiword!

  4. Sorry that it took me so long to answer – but I didn’t get around to mess with Siag until today. I took a look at the pet file you provided the URL for but I decided not to follow that shortcut but instead write proper PKGBUILDS for them and build the libraries natively. This worked quite well. I also got Siag compiled without any errors.

    There’s just one thing: You mentioned reinstalling the fonts with pacman. Which fonts did you reinstall? I’m using the package ttf-dejavu and reinstalling didn’t do anything. Siag still panics and complains about the fonts!

    • There’s a bunch of them and I can’t tell which ones pre-existed and which ones I installed! I have ttf-freefont, but also ttf-liberation, ttf-linux-libertine, ttf-mph-2b-damase and ttf-ubuntu-family-fonts. I also have fontcacheproto, fontconfig, fontsproto, libxfont, and libfontcache . Hope that helps, somehow. In this regard, it is likely a lucky case of throwing enough s**t at the wall and having it stick!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s