| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Thu, 2025-02-27 at 17:06 +0100, Rainer Fiebig wrote:
> Am 27.02.25 um 10:26 schrieb Thomas Trepl ([email protected]
> via lfs-dev Mailing List):
> > Am Mittwoch, dem 26.02.2025 um 13:19 -0600 schrieb Bruce Dubbs:
> > > We have a potential problem with LFS and BLFS that I am asking for feedback on how to
> > > proceed.
> > >
> > > CURRENT
> > > We have LFS and BLFS almost ready to go with a few packages (3) that still need
> > > testing on specialized hardware. There are also a few tweaks needed to some
> > > instructions, but there are no show stoppers.
> > >
> > > PROBLEM
> > > I was testing some LFS packages that have come in during the package freeze and
> > > ran into a problem with udev/systemd. This problem is caused by a change in the
> > > kernel headers for linux-6.13.4 that cause udev/systemd to fail. This problem can be
> > > fixed with two seds or by upgrading to systemd-257.3 but we cannot be sure that the
> > > rest of the many applications and libraries that depend on systemd/udev will work
> > > properly unless we go through extensive testing. The changes are not needed for
> > > what we have now using the linux-6.13.2 kernel.
> > >
> > > The problem now occurs if a user upgrades the kernel when building LFS. We say:
> > > "The Linux kernel is updated quite frequently, many times due to discoveries of
> > > security vulnerabilities. The latest available stable kernel version may be used,
> > > unless the errata page says otherwise."
> > >
> > > Here are our options:
> > >
> > > 1. Continue with the 12.3 release. We can add to the errata to tell users NOT to
> > > use the latest kernel or we can remove that quote above.
> > >
> > > 2. We can release a new lfs-12.3-rc2 and restart the testing process. This
> > > will delay the release schedule by one to two weeks but will make upgrades
> > > easier for users. It will also allow us to incorporate newer package versions
> > > that have published security issues.
> > >
> > > I'll note here that there is no guarantee that during the delay that new
> > > packages with security issues will not be released. Sometimes a new package
> > > is not an issue, but the current problem is that udev/systemd touches a huge
> > > number of packages and we don't have a good way to ensure everything is
> > > consistent without re-testing everything.
> > >
> > > I am asking for community feedback about how we should proceed.
> >
> > I'd suggest to add (and finally choose) a third option:
> >
> > 3. Change the note to "The Linux kernel is updated quite frequently, many
> > times due to discoveries of security vulnerabilities. The book has been
> > tested on the documented kernel version of &kernel-version;. If there are
> > newer versions, those version might be used if there are urgent reasons,
> > but there is no guarantee that newer kernel version can be just dropped in
> > without impact on user land programs." (or so)
> >
> > So we can stay on 6.13.2 and release it as is. Kernel upgrades do occur
> > very often and when we tell the user to always use the latest, it would
> > mean the user has to redo LFS every some days and our "release" is rendered
> > invalid.
> > We know that 12.3 works pretty fine on 6.13.2. Thats good and it is a
> > pretty good starting point for a user looking for a stable system.
> OK, but no user would expect a _minor_ point-release of the _kernel_ to
> break the build. Linux-6.13.5 is out already. Does anybody really
> expect a user not to take that version if he can? With the latest fixes
> or drivers? And who would want to explain that 6.13.2 is good but
> 6.13.5 is "no-no"?
The problem is in general changing *any* version can blow up the build.
And we cannot control if the upstream classifies a release as "minor" or
not. To me the definition of "minor" is some arbitrary decision from
the upstream developers.
That's why all non-rolling distros like Ubuntu *never* upgrades packages
randomly for a stable release, they only apply patches if there's a
security or important fix.
On the other hand the rolling distros like Arch tolerates a build
failure caused by a dependency update. Such a build failure is only
fixed when someone spots it (or when they deliberately trigger a rebuild
to detect such a failure).
The BLFS development is like a rolling distro, but the BLFS stable is
like a non-rolling distro.
> Update the udev/systemd-stuff, take the time needed for testing and
> simply postpone the release accordingly. The "schedule" mentioned in
> this thread is just an internal thing. Completely unimportant for the
> users.
Again the problem is *in general* such thing may happen with *any*
upgrade, perhaps just after finishing the tagging for rc2 we'll
immediately hit another one.
The problem is NOT simply "Linux API headers vs systemd/udev." It
indicates a large contradiction: we've been attempting to make (B)LFS
stable a "non-rolling distro with security response" with a wrong way
(randomly upgrading packages and blindly believing they'll work). And
"using the latest kernel point release" is a direct result from the
attempt above, it's not some random policy completely based on belief,
nor for supporting the latest hardware (using the latest point release
is NOT enough for supporting the latest hardware, new drivers are very
rarely backported to point releases for stable branches).
I will still vote for 2 unless we can implement the correct non-rolling
distro maintenance method now immediately (it seems not really practical
considering the current editor team is so small and many [all?] editors
are not real programmers): it's at least better than 1 to me. But I
must point out the problem is not localized to two specific versions of
Linux API header and systemd, it's something larger affecting the entire
(B)LFS.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page