Re: Moving packages from/to BLFS to/from LFS

On Thu, 2025-09-04 at 08:19 +0200, Thomas Trepl wrote:
> Am Mittwoch, dem 03.09.2025 um 19:52 -0500 schrieb Bruce Dubbs:
> > I just finished moving pcre2 from BLFS to LFS needed by grep and less.
> > 
> > By my count we now have 98 packages in LFS.  The process has made me
> > think that 
> > perhaps we should have a few more that are used very frequently in BLFS. 
> > Here is a 
> > list for discussion:
> > 
> > sqlite: see https://wiki.linuxfromscratch.org/lfs/ticket/5784
> >    We probably want to add libarchive to get unzip for the sqlite
> > documentation.
> >    There are 38 references to libarchive in BLFS.
> >    We also may want to consider just archiving the separate zip and unzip
> > packages
> >    in BLFS.  Are they useful?
> > 
> > libxml2: It's not strictly necessary for LFS, but there are 64 references
> >    to it in BLFS.
> > 
> > intltool:  This is already in LFS with a proposal to move it to BLFS
> > along
> >    with it's dependency of XML::Parser.  They are not strictly needed in
> > LFS
> >    but Arch shows 234 packages that need it.
> >    https://archlinux.org/packages/extra/any/intltool/
> >    I have not counted the number of BLFS packages in that list, but from
> > my
> >    standpoint the minimal size and build times don't lead to a compelling
> >    case to move them.
> >    See https://wiki.linuxfromscratch.org/lfs/ticket/4964
> > 
> > There may be other candidates for moving, so let's discuss.
> > 
> >    -- Bruce
> 
> I'd be carefull with moving packages around. At the moment, it looks like
> it is supposed to be done because it is to avoid a recompile of that
> package in BLFS.
> 
> But moving to LFS often means to loose some (optional) features - for
> instance, in libarchive which is also discussed in this thread to move,
> there is a optional dependency to nettle. When moving libarchive to LFS,
> libarchive will be limited to not use nettle except it is recompiled in
> BLFS after nettle is installed. But wasn't this recompile the process which
> should be avoided?

--with-nettle: This switch sets Nettle for crypto support instead of
OpenSSL.

We have OpenSSL in the LFS book, so there's no need to use Nettle at
all.  You cannot enable OpenSSL and Nettle for a libarchive build at the
same time, and OpenSSL the default even if Nettle is installed.

FWIW I added the command explanation as the result of an investigation
after on some of my systems I found nettle is installed but used by
nothing.

> When sqlite is moved to LFS, it does not mean that Python doesn't need to
> be recompiled again in BLFS. The bluetooth and Tk support is not builtin so
> Python need to be recompiled for users how need that features anyhow. It is
> assumed that the majority of the users does not need that functionalities,
> but is it known?

It's an optional dependency.  If we assume the majority of the users
need that, it should have been a recommended dependency.

> But when it is started to add multiple packages to LFS just for convenience
> but limiting them in options for the user, then i think we would create a
> bit headage when things no longer work for them as they did before and it
> will turn out that a silently missing dependency is the cause.
> 
> OTOH, recompiling is done often in BLFS, That is shadow for pam, gcc for
> other langs

In fact GCC is a very bad example here.  We can just enable all the
extra languages listed in BLFS for LFS if we want.  The languages
needing a bootstrap binary is already kicked out even from BLFS.

There's no missing optional dependency in this case, at all.  The only
reason we enable those languages in BLFS but not LFS is to save some
time for the majority of users who don't need them.

If you really need some language enabled in BLFS but not LFS, the
easiest way is just adding it when you build LFS, instead of rebuilding
GCC and waste much more time.

So I said it's a very bad example because it actually contradicts with
your opinion.  It's in fact, indeed an example of we do something "for
convenience but limiting them in options for the user" (here the option
is to just enable those languages in LFS), and assuming the majority of
users don't need something (here Fortran, Objc, and etc.).

And I'd not say "limiting the user's option" is wrong in nature.  The
book is in fact, just a limit of the user's option.  If you really want
to be unlimited you can throw away the book and build a system following
your intrigue, or fork the book and make whatever change you want.

The actual case where we should rebuild GCC following BLFS is upgrading
GCC to a new version.  In this case we should use "--enable-bootstrap"
instead of "--disable-bootstrap," because the latter is only good in LFS
since we've in fact manually bootstrapped it there.

If we don't care about saving the build time and move the BLFS language
list to LFS, we can just document "--enable-bootstrap" in the LFS page
and remove the BLFS page instead.

> Python for sqlite/bluez/Tk support, maybe others too. So it is
> done anyhow.
> 
> I'd refuse from moving pkgs just for conveniece but limiting those packages
> to not fullfill all their dependencies. That would force the user to
> recompile again, so what was the benefit for that user in moving the pkg to
> LFS?

> Other users who do not need that functionalities need to compile the
> package anyhow, either in LFS or later in BLFS if they need it. 

So how about things like --disable-lastlog2 in util-linux?  If you have
installed sqlite and pam you can remove it and enable this feature.  So
should we copy a util-linux page to BLFS?  IMO no, instead we can just
document the affair in the LFS page for the package and/or the LFS
dependency page.

Or how would we justify Python 3 Tk/Bluetooth deserves a page because
"maybe someone needs them" but lastlog2 does not?  Just because Python 3
happened to be in BLFS for reasons completely unrelated to Tk and
Bluetooth?

So to me the only reason we have a Python 3 page in BLFS is to build it
with Sqlite for building Mozilla things.  Tk/Bluetooth shouldn't be
considered a reason, otherwise the same reason would also apply for
Util-linux, Gettext, Man-DB, Make, etc. and we'd duplicate all of them
in BLFS.  To me doing so would be completely counter-productive.

> Strictly spoken that would mean a package can only be moved to LFS if it is
> needed by several other packages and has no other dependencies which are
> not fullfilled in LFS. I assume some packages in LFS do already not match
> that requirement but it seems that they are very rare.

But why pcre is moved?  Only grep needs it.  And we don't even have a
package in BLFS which needs a grep built with pcre.

Either we shouldn't move pcre at all or we should also move sqlite.  I
don't really care so much about rebuilding Python 3 in BLFS, but I care
about consistency.

If we really cannot make a consensus IMO we should keep the status quo,
i.e. moving neither of pcre and sqlite.

-- 
Xi Ruoyao <[email protected]>

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page