linux-from-scratch/lfs-buildscripts
1
0
Fork 0
mirror of https://github.com/YellowJacketLinux/lfs-buildscripts.git synced 2025-01-23 22:42:28 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Mumbling about stuff

Browse Source
This commit is contained in:
YellowJacketLinux 2024-10-07 20:55:20 -07:00
parent 8c76a0c807
commit 9e0a31d9a5
2 changed files with 358 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

254
THE-PLAN.md Normal file
View File

@ -0,0 +1,254 @@
The Plan
========
This is an attempt to create a new GNU/Linux distribution. The why I will
document elsewhere.
The new distribution will be called ‘Yellow-Jacket GNU/Linux’ (abbreviated as
‘YJL’) and will be heavily based upon ‘Linux From Scratch’ (LFS) but will have
many influences from my years with Red Hat Linux, including use of RPM as the
package manager.
I first started this in early 2023 however my efforts were cut short by a busted
water pipe in the ceiling over my bedroom, which also is my office. Extensive
water damage resulted.
After that, there were some medical issues with family members that took a lot
of my time and *still* take a lot of my time, but I am back on track.
Initially, YJL was going to use SystemV Init and the LFS I built in early 2023
is a SystemV Init system. However I am now convinced that SystemD is the better
way to go even though I really like the simplicity of SystemV Init.
Phase One: LFS Bootstrap
------------------------
This phase is what this git repository is about. Create the needed shell scripts
to build the current SystemD LFS (12.2 as I type) on a USB thumb drive that can
then boot an 'x86_64' system and rebuild itself to the hard drive of that
system. It does not need to be able to make a network connection, the needed
source tarballs and patches and scripts will be preserved in '/home/lfs' on the
bootable USB thumb drive.
I am hoping a 128 GB thumb drive will be enough.
My build host is the LFS 11.3 system I build in 2023 (fortunately my PC did
survive the water damage). As of today (2024-11-07) I have LFS 12.2 properly
building through Chapter 8 with my minor modifications (e.g. LibreSSL) but
the build scripts do need some work still and stripping binaries etc. still
needs to be scripted.
I am using '/mnt/newlfs' as the install path rather than '/mnt/lfs' because I
do not want someone playing with these scripts to accidentally nuke their own
LFS system.
If someone stumbles upon this repository, do not use it to learn about LFS.
Do the LFS project from the LFS book. These scripts are for my automation of
my way of doing things which are not necessarily the best way build an LFS
system to learn about GNU/Linux.
Phase Two: GCC Bootstrap
------------------------
The GCC built by LFS does not support building the Ada or D compilers. Both of
those compilers are useful on a GNU/Linux system.
Once I have a hard-disk install booting, the very first order of business is to
rebuild GCC for full compiler support.
To compile GCC with Ada and D support, a working Ada and D compiler is needed.
My LFS 11.3 system has those. What I did back then, on CentOS 7.9 (my build host
for LFS 11.3) I built GCC 7.5.0 with Ada ('gnat') and D ('gdc') support, with an
install prefix of '/opt/gcc750'. GCC 7.5.0 was the newest GCC I could get to
build in CentOS 7.9 with Ada and D support.
I had to copy a few shared libraries from the CentOS 7 system into
'/opt/gcc750/lib' but once I did that, I was able to use that GCC in LFS 11.3 to
then build an Ada and D capable GCC 10.4.0 within '/opt/gcc1040', GCC 7.5.0
would not succesfully build an Ada and D capable GCC 12.2.0.
However I was then able to use GCC 10.4.0 to build the Ada and D capable GCC
12.2.0 which is the GCC version in LFS 11.3.
For the LFS 12.2 GCC bootstrap, I *suspect* I can use the Ada and D capable GCC
GCC 12.2.0 in LFS 11.3 to build an Ada and D capable GCC 14.2.0 installed in
'/opt/gcc1420' that I can then use in LFS 12.2 to bootstrap the system GCC, of
course running the full test suite before installing.
I tried adding Ada and D support to the GCC building of LFS 12.2 Chapter 5 and
it caused a build failure, so it is *possible* I will need another intemediary.
Anyway, boostrapping an Ada and D capable GCC within LFS 12.2 will be my first
priority once it is booting.
Phase Three: RPM Bootstrap
--------------------------
The needed libraries to build RPM will need to be built and installed, and then
RPM will be built and installed.
Once RPM is built and installed comes the long and tedious task of writing the
needed RPM spec files to rebuild every package on the system in RPM. Much of
that work has already been done from my LFS 11.3 system but the spec files need
to be updated and some still needed to be written when the water pipe broke.
Phase Four: XFCE
----------------
Once the system is RPM bootstrapped, I can start building the software needed
for the XFCE desktop environment.
My *personal* preferred desktop environment is actually MATE but XFCE is what I
am building as the default desktop environment for YJL.
Phase Five: Installer
---------------------
With XFCE running, an bootable USB thumb drive that can install the system from
RPM packages will have the be created. That will be when YJL becomes a reality
and not just a concept I am working towards.
Beyond YJL
----------
I really dislike the current GNU/Linux ecosystems where a distribution tries to
package everything under the sun.
I much preferred the older days, pre Fedora, when 'yum' was new and you could
install Red Hat Linux and then use add-on package repositories that met your
specific needs.
YJL will be kept small with a boring LTS kernel, the idea is that those who want
something different than my *personal* vision can build package repositories
that meet *their* vision and needs.
Maybe there could be a small package repository with software suited for running
a Mastodon server. Maybe there could be a small package repository with software
suited for running a video streaming service. Maybe there could be a small
package repository with software suited for running a competitor to Overleaf
that actually uses a current TeXLive backend.
I will probably maintain a package repository for MATE. I have no desire to
*personally* maintain one for GNOME or KDE or whatever but if there are people
who do have such a desire, they can run those repositories even with the freedom
to have their repositories *replace* YJL packages as needed.
YJL Kernel Philosophy
---------------------
Back when I first started using GNU/Linux, it was fun to always run the latest
kernel. In fact, I would run the ‘Alan Cox’ patch to the 2.4 series.
Benefits to running the bleeding edge kernel now do not seem as apparent to me
and maybe they were only imagined back then.
I am not a kernel hacker and even if the YJL project takes off, hiring a kernel
hacker does not seem like a wise use of resources. By running a LTS kernel in
YJL, security issues can be fixed by updating to the latest in the LTS series
from 'kernel.org' without needing to backport patches. Using an LTS kernel means
that YJL does not have to hire a kernel hacker to remain secure without needing
to break some systems with a kernel update when a particular kernel series is
no longer maintained, the LTS kernels are maintained for a very long time.
Users who want a newer kernel are absolutely free to build one and I am sure
that many will, but then compatibility issues are their issue, not the issue of
YJL.
Some examples of where this is an issue: I had a system in a room without a
wired network jack. I went and bought a PCI WiFi card with a Tux logo on it that
claimed Linux compatibility. Well, that was only partially true.
The card required a closed source driver that worked just fine with older
kernels. In fact for CentOS, 'elrepo' had a package for it, but I could not get
the card to work in Fedora because the kernel was too new. I also had a similar
issue with an nVidia GPU.
Using an LTS kernel does not guarantee that such hardware will work however when
the hardware does work with the kernel, it it likely to continue working with
updates to the same LTS kernel series.
Users and add-on package repositories are of course free to package kernels from
newer series but then what to do when 'kernel.org' stop pushing updates to that
series is their problem, not mine. They can backport fixes, or they can update
to an even newer series, but doing the latter may break some systems.
I actually encourage people to build their own kernels using a kernel
configuration that is well-suited for their specific hardware, and of course
many users will decide to do so using a newer kernel series. The LTS kernel that
ships with YJL should be a safe generic kernel configuration but the user need
not be restricted to those options.
I would like YJL to have a tool that allows users to specify what kernel series
they would like to use that then monitors 'kernel.org' for updates to that
series and then creates a 'src.rpm' for them (using 'make oldconfig') that they
can rebuild and install. Sometimes updates have new options so it can not be
totally automated. Of course such a tool would need to verify the signature of
the updated source.
### YJL Versioning
YJL itself will only ship a LTS kernel and the series shipped will be used as
the version number of YJL. For example, the current LTS kernel I am using is
the 6.6 series so if I shipped YJL today, it would be YJL 6.6.
If this project does take off, it is probable that I will not ship a new
version of YJL every time 'kernel.org' tags a new kernel series as an LTS
series. There is a good chance I will only make a new YJL for every other LTS
kernel.
The 6.6 series was initially released in October, 2023 and has a projected EOL
of December, 2026. My guess is there will be another LTS series before I have an
installer ready, and that it will likely also have about a three year lifespan.
My guess is that the initial installer will probably have kernel configuration
that needs a lot of improvement. Updated installers with updated packages are a
sure thing. A hyphen can be users for that, e.g. ‘YJL 6.6-3’ would indicate the
third installer revision of YJL that uses the 6.6 LTS kernel series.
TeXLive Philosophy
------------------
I am an avid LaTeX user, since the days of teTeX before TeXLive was a thing. I
hate distribution packaging of TeXLive.
If someone wants to create an RPM package repository for TeXLive packages, more
power to them. The problems I have is that it really is better to just have all
of CTAN anyway and when you have been using TeXLive for any amount of time, you
likely want to have several versions around.
If I need to tweak a document I made in 2016 using pdfLaTeX from TeXLive 2016,
there is a decent chance it will properly compile in TeXLive 2024 but very often
I find I need to make a lot of changes to it. However if I instead make the
tweak and rebuild it using pdfLaTeX from TeXLive 2016, there very rarely is an
issue. I might port it to LuaLaTeX in a modern TeXLive if I think there will be
more than just a tweak made, but if I just need to tweak it, it is good to have
the old versions available.
TeXLive should be installed in '/opt/texlive/YYYY' where 'YYYY' is the year.
The system should have a user named 'texlive' that has write permission to it,
and that user account can update the install as needed using 'tlmgr' and when a
new version of TeXLive is released, the 'texlive' user can install it without
nuking the older versions.
YJL will provide the shell scripts needed to set this up, YJL will not package
TeXLive. Third parties that want to create an RPM package repository, have at
it, I just think distribution packaging is the wrong approach to TeXLive.

104
THE_WHY.md Normal file
View File

@ -0,0 +1,104 @@
The Why
=======
Well, this is at least a partial explanation at *why* I am attempting to create
my own GNU/Linux distribution.
I have less and less fond of the current GNU/Linux distribution landscape. It
seems that each distribution has a specific way of doing things and you do it
their way or do not do it at all. Each distribution likes to package everything
under the sun and you use their packages or you build from source.
I have a different philosophy. I do not like monopoly power. I do not like the
power that Amazon has, I do not like the power that Facebook has, I do not like
the power that Chase has, I think diversity in options is key to consumer
quality.
It is true that there are many different GNU/Linux distributions to choose from
but it seems that each one is trying to be a monopoly power and dictate how
things are to be done.
The first GNU/Linux distribution I ever used was MKLinux DR3 on a PowerPC G3.
For those unaware, MKLinux DR3 was a port of Red Hat 5.1 to the Mach Mikrokernel
by Apple Computer.
Before long I was running LinuxPPC 1999 (a port of Red Hat 6) and it was on
LinuxPPC 1999 that I first did the LFS Project, LFS 2.0. That is where I learned
the most about GNU/Linux.
Eventually I ended up on 'x86' hardware running Red Hat Linux. Life was good.
Red Hat provided a good base and there were several different third party RPM
packagers for software beyond what Red Hat provided. When I say life was good,
of course we will ignore the whole GCC 2.96 debacle...but the third party
package repositories provided GCC 2.95.
And then Fedora happened. Fedora as ‘Fedora Extras’ was a good thing, and it was
not the only option people had to extend software beyond what shipped with Red
Hat. But then Red Hat Linux ceased and became Fedora Core and then Fedora. The
software was always bleeding edge and just when it started to mature and become
stable, it became ‘End of Life’ and us users were forced to install a new
version with new bugs. I hated it. Basically it was not profitable for Red Hat
to produce a consumer distribution so they turned it into a testing ground for
their Enterprise product. To their corporate mindset, us users were nothing more
that free beta testers for what would go into their commercial enterprise
product (RHEL).
I switched to CentOS at that time. The software wasn’t bleeding edge, but it was
stable and it worked. CentOS 5 was my first version of CentOS.
When necessary---such as with Apache, MySQL, and PHP---we could install newer
versions on it either from source or from add-on repositories, but the operating
system itself was solid and stable and well-maintained.
CentOS (developed as a clone of RHEL) became aquired by Red Hat and CentOS 7 was
the last version I felt comfortable with. I simply do not like the direction
that Red Hat has gone with it.
Debian is still a really good choice, I ran it on an m68k system (Apple SE/30 to
be specific) back when I was first learning GNU/Linux but I felt like I just did
not fit into the Debian world. At the time, mail lists were the method of user
support and the mail lists for Debian seemed more hostile to me than they were
in the Red Hat world, I just did not feel welcome.
The issue, my brain works differently. I am not dumb but I do not always
understand explanations people give because my brain works differently. On the
Red Hat related lists, it seems people were more patient when I had trouble
with an explanation but on the Debian lists, I was treated like an imbecile. So
I never felt welcome in the Debian world. The distribution however is fantastic.
At one point I tried Ubuntu. After installing it, I did not see where the GIMP
was installed so I used their search tool thingy to search for it, and I was
sent to an Amazon web page offering me books on The GIMP. Fuck that, I wiped it
and put CentOS on that system that very day.
I later learned that not only was Ubuntu sending my search request to Amazon but
it was doing it without a secure connection. Who the fuck approved that and why
wasn’t that caught in beta testing? It generated enough complaints that they
stopped doing it but I have to wonder when they will try something like that
again. It seems the bigger a company is, the more likely it is that they lose
sight on the importance of user privacy. The consumer becomes the product they
sell to other big companies, and that even happens in the FLOSS world. In the
FLOSS world though we, the users, have the power to do something about it.
Well, in theory we do anyway.
Fast forward several years...
When it was announced that CentOS 7 was ‘End of Life’ I tried the modern Debian,
Fedora, and Ubuntu options. All of them installed on my hardware and all of them
kernel panicked on first boot. LFS works fine, even with modern kernels, so it
seems that the GNU/Linux distributions have something selected in their kernel
that causes a kernel panic but is not used in their installer. I could try to
track it down, I suspect it was a bug in the open source nVidia driver, but
honestly I think rolling my own GNU/Linux distribution is going to give me
happier results.
Worst case scenario, I am my only user. Would that really be so bad?
My hope is that there are others like me who agree that a small ‘Core’
distribution with user choice in package repositories for software beyond that
‘Core’ is the right way to do things.
Such a philosophy does sometimes result in conflicts between package
repositories but such conflicts can usually be solved without too much work.