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.
Saturday 14 October 2017
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:
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?
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?
Saturday 29 July 2017
Debian priority for packages exim4, mailutils etc. just got set to optional
I'm pissed-off. Maybe it's just because I don't cope well with change.
I'm not a veteran Linux user by any means. I'm pretty much one level above newbie. I just don't like change because it makes learning harder when I don't know what to expect.
So two weeks ago I installed Debian 9 from the "Net Installer" into a VirtualBox VM. Then two days ago I created another VM and did the same install, using the same ISO image, and making the same selections as before.
Only this time, I discovered that the resulting system was missing packages that I expected to be there. The packages were related to mailing on the local system, and consisted primarily of exim4 and mailutils.
After much painful searching (and putting up with unfriendly skeptics on the Debian forums) I finally found out that the reason these packages are no longer installed is because sometime in the past fifteen days, they changed the package priority from 'standard' to 'optional', causing the Net Installer to no longer download or install them.
What the hell? I thought that having a 'mail' command was a standard thing. Well, not anymore, in the world of Debian. They are changing the fundamentals of the system that I got used to. But I guess that's what they want to do, and I guess I shouldn't be surprised by that. The change to systemd was the first major indicator of Debian's new plan.
Well I guess I can't rely on Debian to include the features that a standard *nix system should have anymore. Not that I'm experienced enough to know all the features that rely on mail. I do know that I won't get any output from cron jobs now. But if I file a bug report on that, they'll probably just say "fuck it" and pull cron from their default install as well...
My post to Debian Forums that only got replies from unfriendly skeptics:
http://forums.debian.net/viewtopic.php?f=10&t=134079
My Debian bug report that nobody will care about:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870030
Debian people discussing "cutting some cruft from priority:standard":
https://lists.debian.org/debian-devel/2014/09/msg00480.html
I'm not a veteran Linux user by any means. I'm pretty much one level above newbie. I just don't like change because it makes learning harder when I don't know what to expect.
So two weeks ago I installed Debian 9 from the "Net Installer" into a VirtualBox VM. Then two days ago I created another VM and did the same install, using the same ISO image, and making the same selections as before.
Only this time, I discovered that the resulting system was missing packages that I expected to be there. The packages were related to mailing on the local system, and consisted primarily of exim4 and mailutils.
After much painful searching (and putting up with unfriendly skeptics on the Debian forums) I finally found out that the reason these packages are no longer installed is because sometime in the past fifteen days, they changed the package priority from 'standard' to 'optional', causing the Net Installer to no longer download or install them.
What the hell? I thought that having a 'mail' command was a standard thing. Well, not anymore, in the world of Debian. They are changing the fundamentals of the system that I got used to. But I guess that's what they want to do, and I guess I shouldn't be surprised by that. The change to systemd was the first major indicator of Debian's new plan.
Well I guess I can't rely on Debian to include the features that a standard *nix system should have anymore. Not that I'm experienced enough to know all the features that rely on mail. I do know that I won't get any output from cron jobs now. But if I file a bug report on that, they'll probably just say "fuck it" and pull cron from their default install as well...
My post to Debian Forums that only got replies from unfriendly skeptics:
http://forums.debian.net/viewtopic.php?f=10&t=134079
My Debian bug report that nobody will care about:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870030
Debian people discussing "cutting some cruft from priority:standard":
https://lists.debian.org/debian-devel/2014/09/msg00480.html
Subscribe to:
Posts (Atom)