mirror of
https://github.com/YellowJacketLinux/lfs-buildscripts.git
synced 2025-01-23 22:42:28 +08:00
Mumbling about stuff
This commit is contained in:
parent
8c76a0c807
commit
9e0a31d9a5
254
THE-PLAN.md
Normal file
254
THE-PLAN.md
Normal 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
104
THE_WHY.md
Normal 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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user