Important Basilisk Linux Build Changes

Board for discussions around the Basilisk web browser.

Moderator: Basilisk-Dev

User avatar
Basilisk-Dev
Lunatic
Lunatic
Posts: 323
Joined: 2022-03-23, 16:41
Location: Chamber of Secrets

Important Basilisk Linux Build Changes

Unread post by Basilisk-Dev » 2023-09-14, 13:30

Partially copied and pasted from my comment here: https://repo.palemoon.org/Basilisk-Dev/ ... ment-37653

I thought that switching to a distribution from 2014 to a distribution from 2016 for Basilisk builds would be old enough that no one would notice but apparently that isn't the case...

Previously we were using CentOS 7 to build our releases. Due to distrust of Red Hat due to recent events regarding the IBM acquisition and their subsequent removal of public access to their SRPM files for RHEL, I've moved away from using any RHEL based distro for any and all future builds.

Our builds are now built upon Slackware 14.2. We chose this specific version because like RHEL, it is several years old so binaries built on Slackware 14.2 will run on many modern versions of Linux. Also, like RHEL, it still receives security updates several years after its original release.

For reference in terms of timeframes, CentOS 7 was released in July 2014. Slackware 14.2 was released in June 2016.

Builds would have lost compatibility with CentOS 7 in the next year regardless of if I had made the migration to Slackware or stayed with RHEL based distributions due to the fact that CentOS 7 support ends in June 2024. If I had stayed with RHEL based distributions I would have migrated to something based upon RHEL 8 at that time. RHEL 8 was released in September 2019. Slackware 14.2 is much older than RHEL 8 so this choice breaks compatibility for less users than switching to RHEL 8 would have.

Sorry for those using any really old distributions that can no longer run Basilisk.
Basilisk Project Owner

viewtopic.php?f=61&p=230756

User avatar
andyprough
Keeps coming back
Keeps coming back
Posts: 752
Joined: 2020-05-31, 04:33

Re: Important Basilisk Linux Build Changes

Unread post by andyprough » 2023-09-14, 14:27

It's worth noting that Debian 8 "Jessie" was released in 2015 and is covered by free Extended LTS until 2025. Slackware versions 14 through 14.2 support could be cut off at any time according to the notes I've read from Patrick Volkerding, although I'm sure he would give plenty of advanced notice. All versions of Debian since version 8 now have the 10-year ELTS option through the freexian project. Just an option in case you ever need it.

User avatar
Basilisk-Dev
Lunatic
Lunatic
Posts: 323
Joined: 2022-03-23, 16:41
Location: Chamber of Secrets

Re: Important Basilisk Linux Build Changes

Unread post by Basilisk-Dev » 2023-09-14, 16:17

andyprough wrote:
2023-09-14, 14:27
It's worth noting that Debian 8 "Jessie" was released in 2015 and is covered by free Extended LTS until 2025.
Debian's not really something I am interested in, but I do appreciate the suggestion. I have had worse experiences with Ubuntu and Debian than I have with any other Linux distribution family. Even in the past when I used to run Gentoo I had less issues than I had with Debian and Ubuntu.

They are the only 2 Linux based or Unix like operating systems I have ever ran outside of Arch Linux where major OS upgrades would consistently completely break my system to the point that a reinstall was required. I also had a ton of breakage when I tried to run Debian Testing (not Sid) as a desktop at one point. My experiences with those two distributions happened over 8 years ago in the case of Ubuntu, and over a decade ago in the case of Debian, so it's possible things have changed now but those experiences have really put a sour taste in my mouth to dpkg based distributions in general.

I also don't really like the fact that they have Debian and Ubuntu specific patches for libraries and applications. I think software that you are packaging for a distribution should be patched as little as possible so that any bug reports you may have are actually correct and relevant to the upstream provider of that software. For example, I think patching to fix a build issue is fine. Patching because Debian does something in a non-standard way and they want to force the program to work in their non-standard way isn't acceptable IMO.
Basilisk Project Owner

viewtopic.php?f=61&p=230756