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

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?

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?

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, 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. 

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.

-- 
Thomas

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