[lfs-dev] New packages in LFS
bruce.dubbs at gmail.com
Fri Oct 6 09:09:54 PDT 2017
Thomas Trepl wrote:
> Am Samstag, den 23.09.2017, 17:32 -0500 schrieb Bruce Dubbs:
>> I have added four new packages to LFS: libffi, python3, ninja, and
>> Please take a look and let me know of any issues/suggestions/typos
>> For those who do not render the book themselves, it will be rendered
>> overnight on the main web site.
>> I have not changed systemd. I ask either DJ or renodr to make
>> changes and
>> test the systemd build using meson/ninja. There are other packages
>> BLFS that can use meson and I suggest we move to that build mechanism
>> it seems to be a lot faster and cleaner than autotools based builds.
>> We will be able to remove libffi from BLFS and meson will not be
>> there, but python and ninja will still need to remain for additional
>> optional dependencies.
>> -- Bruce
> looks like this packages are only required for systemd. My suggestion
> would be to add this packages only in the systemd-branch in order to
> not "pollute" the sysv-branch; just the same way as systemd itself does
> only appear in the systemd branch.
> Since there are many dependencies in Python (bluez, openssl, etc.) the
> Python installation here in LFS is only temporary to get the build
> tools meson and ninja running. Since those tools are required more or
> less only for gnome stuff, they need to be built anyhow, but only if
> systemd/gnome stuff is required. If they are not built in LFS, it does
> not cost anything to build them when needed later in BLFS.
> Apropos openssl - there are options in the kernel config which adds a
> dependency to openssl to the kernel. A full featured kernel (like the
> one you get when using Archlinux's config) does not build without
> having openssl installed. With this said, it looks to me more important
> to have openssl in the basic tool chain than the ones above (except you
> do a systemd build).
> What do you think?
When I added the packages, I did consider limiting them to the systemd
version of the book only. My conclusion was that they really didn't
degrade very much. Let's look at the packages:
libffi: this package does not have any dependencies in BLFS and has 11
packages in BLFS that depend on it. It is true that if you are building a
server without a gui, then it is probably not needed, but most people do
python3: This is a general purpose tool used in 34 packages, Having it
in LFS simplifies BLFS by quite a bit. It does need to be rebuilt in BLFS
if you want it to support bdb, bluez, openssl, sqlite, or tk, but all
those are optional. I know of no packages in BLFS that depend on python3
needing these extra modules. I feel that rebuilding pythin3 will be the
ninja: This is starting to be used by a lot of packages beyond
systemd/gnome. It only needs to be rebuilt in BLFS to create
documentation. We are considering adding a small LFS built file with the
man pages. Another option is to add asciidoc that only depends on python3.
meson: Again, some non-systemd/gnome packages are going to this package.
It has no other dependencies and does speed up the build process by
quite a bit. It's a reasonable addition in LFS that in turn requires the
openssl: Adding this to lfs has been proposed. It has no dependencies,
but it would be one more file.
One last issue is that we try to keep the sysv and systemd version of lfs
as close as possible. The only packages in systemd not in lfs are systemd
itself and dbus. The reason for omitting dbus is that it needs to be run
as a daemon that may not be needed in blfs. The packages in systemd
omitted are eudev, sysvinit, and sysklogd which supply capabilities
included in systemd.
More information about the lfs-dev