Saturday 14 October 2017

What if I Want to Mirror End-of-Life CentOS?

I wanted to make a local mirror for some personal systems running CentOS 5.  It is now EOL, and I didn't mirror it before that happened.  It is easy to mirror an EOL release from Debian or Ubuntu, but CentOS doesn't make it easy.  In fact it seems impossible, but I don't know if that was the intention.

The CentOS team keeps EOL releases at vault.centos.org.  But unfortunately, that is the same server that worldwide mirrors connect to for current releases.  And according to https://wiki.centos.org/HowTos/CreatePublicMirrors, you cannot sync from that server because they have restricted access to only the known public mirror IP addresses.

Well, fuck.  I can't use vault.centos.org and I can't use any of the worldwide mirrors - because they don't keep EOL versions.  So, for anyone wanting to create their own mirror, it's up to luck.  I guess today I was lucky.  I found a site that keeps older releases AND which lets me rsync (there are only a few and most do not support rsync access).  It is at kartolo.sby.datautama.net.id/Centos/.

Well I am thankful for the existence of a 3rd-party mirror, but it really bugs me that CentOS has locked people out of mirroring their own official source for EOL releases.  I might complain if I feel like it.  But if they don't fix this bug, I shall make sure to grab the next current release before it goes EOL.

Thursday 5 October 2017

Checkinstall is Unmaintained and Broken - How Could That Happen?

While I have been a Linux user for a number of years, I have been slow to adopt good policy regarding the management of a Linux system.  When it comes to installing software, I rarely ventured beyond the use of my distribution's repositories.  When I did, I would almost always find that the procedure was to compile from source using the traditional "./configure", "make" and "make install" commands.

During the past few weeks, I have been installing the latest version of a program that isn't in the repositories.  It is available as source code, and as usual, is compiled using the above three commands.  Only I became more aware than I did in previous years about the disadvantages of that method.  Primarily, there is no guaranteed way to uninstall the software, as various files are distributed all over the filesystem without keeping any records of what went where.

I remembered the first time I read about this disadvantage on a Mageia Wiki page.  It taught me that not only do you have the difficulty of uninstalling, you also risk making your system unstable.  From that wiki, I remember clearly their advice:

"The golden rule is, never bypass the rpm package database, if you can possibly help it..."
 It offered a way to install from source that was more sane: use Checkinstall instead of "make install" and it will not only keep track of the files installed, it will enter them into the RPM or DEB database and produce a package for you to install anytime in the future without having to recompile.

My first systems on which I used Checkinstall were two Ubuntu 14.04 systems.  It was in the repositories and I used it without error.  Then I went to a Debian 8 system, and installed my program there using Checkinstall as well.  It was great.  I found a sane way to install any program from source code without losing track of which files went where, and I also avoided any potential instability of my systems.

So then I went over to another system that was running CentOS 7, and found that Checkinstall wasn't available in the repositories.  This was strange, I thought.  So I searched https://pkgs.org for any third party repositories that might have it.  I could only find an RPM package for the old CentOS 5.  Okay fine, I said, I will just have to install Checkinstall from source.

I found the home page of the Checkinstall project, and I was happy to find after reading the documentation that there was a way to use Checkinstall on itself after installing so that it would be entered into the package management database.

But then I saw that the last release was in 2016, and there was no news or updates for this year.  That was worrisome to me.  Anyway, I went ahead and downloaded the source archive and proceeded with the unpacking and preparation steps to configure and make on my CentOS system.  Only it didn't make.  It threw a ton of errors which I am not skilled enough to solve.

So I searched for a possible solution to get Checkinstall working on CentOS 7, only to find more and more bad news.

Checkinstall uses a utility called "Installwatch", which, according to Wikipedia, has not been functioning completely right for the past 10 years.

After learning all this,  I gave up trying to find a way to get Checkinstall to work on my CentOS 7 system and just ran the untidy "make install".  But I was really pissed-off.  Why is it that a piece of software like Checkinstall, which seems to be the most sensible way to achieve and maintain a sane and stable Linux system when installing from source, is so terribly neglected?  What the fuck is going on?

Maybe there's a newer project out there that replicates that functionality, but I have yet to find it.  My question is, in 2017, what the hell does a Linux user have to do to get a source software package installed cleanly?  Does it require learning to build DEB and RPM packages?  I don't know what that entails, but it probably is a lot more complex than running one command.

I do hope that we're not at risk of losing a traditional way of doing things.  I know that there is a lot of design and skills needed just to create a source software package that works with the configure/make/make install trio, and one day I will have finally learned to code and I will know how to set up the source package to configure and compile in this manner. Maybe I will even become the maintainer of the Checkinstall software.  It seems to me like a very important project in the realm of Linux.  I just wonder though, why isn't anybody else doing this job?