lfs-rpmbootstrap/README.md

Bootstrapping LFS 12.2 (SystemD) with RPM
=========================================

This git contains the RPM spec files and text sources/patches not retrievable
easily from a hyperlink for RPM bootstrapping my LFS 12.2 SystemD system.

The is ‘Phase Four’ of [`THE-PLAN.md`](THE-PLAN.md).

Many of the spec files are ported from my previous (incomplete) RPM bootstrap of
my LFS 11.3 SysV Init system but due to a hard drive failure, some of those RPM
spec files were lost and I need to start over.

The RPM spec files committed today (20 October 2024 UTC) all build *except* for
the GCC RPM which is being worked on. With GCC, currently there are installed
files that need to be put into the correct place. Also, I need to add `m2` to
the list of compilers and create a sub-package for it.

The Perl spec file builds packages but needs to be split up into lots of smaller
packages. For RPM bootstrapping, that does not matter. That is a lot of tedious
work but the value is a small bug fix in a bundled module can then be updated
via RPM without needing to rebuild all of Perl.

The GLibC spec file has a bug. Other packages detect they need `rtld(GNU_HASH)`
which I believe is provided by GLibC but the packaging of GLibC does not detect
that it provides it. I could auto-specify that it provides it, but part of me
wonders if there actually is a runtime dependency for RPM missing that prevents
RPM from automatically picking up that GLibC as compiled?

Yes, `binutils` is compiled with `--enable-default-hash-style=gnu` and clearly
it is working as RPM detects `rtld(GNU_HASH)` as a needed dependency, but for
whatever reason, the RPM build of GLibC does not auto-detect that GLibC is
providing it.

Many of the spec files undoubtedly need work. Many undoubtedly have missing
`BuildRequires` and other packaging mistakes.


Duplicate Documentation
-----------------------

By default, LFS/BLFS does not compress man or info pages. By default, RPM uses
gzip compression on man and info pages. Thus when RPM bootstrapping an LFS
system, you will likely end up with two copies of each man and info page.

One solution is to gzip all man and info pages *before* the RPM bootstrap. That
way the files on the file system will have the same file name as the file names
in the RPM files. Similarly, you can configure your RPM build environment to NOT
gzip the man and info pages. Then once the bootstrap is complete, revert it to
gzip in future package builds. However, I just use a shell script to find and
delete the duplicates. Since RPM compresses them and the script only deletes the
uncompressed duplicates, it does not remove files under RPM management.

The shell script [`remove_duplicates.sh`](remove_duplicates.sh) can be used to
remove the duplicates. Run it once a day or so during the RPM bootstrap process,
definitely after installing RPM packaged Perl for the first time.


Bootstrap Build Order
---------------------

The build order is not *too* important. At the start, the `--nodeps` switch is
often needed because both library and runtime dependencies are in fact present
but not yet under RPM management, so the RPM database does not know about them.

I started with the [`kernel-abi-headers`](SPECS/kernel-abi-headers.spec) package
because it would be easy to restore that `noarch` package if something went
wrong, and I followed that with the [`vim`](SPECS/vim.spec) package because it
tested a binary build and again would be easy to restore the package if
something went wrong.

I deviated from the LFS instructions for the OpenSSL API stack, using LibreSSL
as my default library for the OpenSSL API stack and only using OpenSSL for
Python which does not support building against LibreSSL. To accomplish that in
the LFS build, LibreSSL was installed with a prefix of `/usr` and OpenSSL was
installed with a prefix of `/opt/openssl`.

With RPM management, both can be built with a prefix of `/usr` with the only
hitch being the `-devel` package for both can not be installed at the same time.

So next I rebuilt [`libressl`](SPECS/libressl.spec) followed by
[`openssl`](SPECS/openssl.spec) with a `/usr` prefix, allowing me to temporarily
uninstall the `libressl-devel` package so I could install the `openssl-devel`
package and rebuild [`python3`](SPECS/python3.spec) linking against OpenSSL
libraries in `/usr/lib` instead of in `/opt/openssl/lib` and the `/opt/openssl`
directory could be deleted.

The `openssl-devel` package was then uninstalled and `libressl-devel` restored
so that other packages that want the OpenSSL API and can link against LibreSSL
to get it would do so. I just *personally* have higher trust in the LibreSSL
developers and I do not care about FIPS certification.

LFS only builds `libelf` from ElfUtils but RPM requires `libdwarf` from ElfUtils
so part of building RPM itself was rebuilding ElfUtils *with* `libdwarf`. I thus
saw that as a deviation from LFS instructions, so next I built the full complete
[`elfutils`](SPECS/elfutils.spec) (using a `eu-` prefix on the binary
utilities).

With GCC I deviated by bootstrapping it with Ada (`gnat`) and D (`gcd`) support,
I am working on a [`gcc`](SPECS/gcc.spec) RPM package that also builds all the
other languages (similar to the BLFS build of GCC). My GCC build also includes
the [Integer Set Library](https://en.wikipedia.org/wiki/Integer_set_library).
With GCC, ISL support can be added by unpacking the ISL source code into the
GCC source code and making sure the directory is named `isl` (as opposed to,
say, `isl-0.26`).

The only other major deviation from LFS is with the `make-ca` script that is
technically from BLFS but that package is shell script only and I will likely
wait until after SystemD is RPM bootstrapped since it uses a SystemD timer unit
to run once a week.

With all of the major deviations packaged *except* GCC (being worked on) and
`make-ca` (waiting until after SystemD is packaged), the order I am following is
pretty much the order in the LFS book starting with Chapter Five. I am not
using the build instructions from the early chapters of the LFS book, most of my
build instructions are *fairly* similar to the Chapter 8 build instructions.

Once GCC is finished and Util-Linux (not yet started) is finished, the plan is
to pause and audit each spec file, making sure things like the specified license
is correct and other things, before proceeding with RPM bootstrapping the
packages in Chapter 8 that are not already RPM packaged.

I may have to do the kernel sooner as there are some kernel options I should
have enabled but did not. My intent is for RPM itself to be the very *last*
package I RPM bootstrap before going on to the next phase (building `dnf` and
`mock`).