[lfs-dev] Regarding left over systemd packages.

Kenneth Harrison maduinthemarauder at gmail.com
Tue May 20 01:17:07 PDT 2014


On Monday, May 19, 2014, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:

> Kenneth Harrison wrote:
>
>> Up till before systemd was experimented with, several packages never had
>> existed in the LFS book until that time. These packages include:
>>
>> expat
>> XML:Parser
>> intltool
>> libcap
>> acl
>> attr
>>
>> Dbus was obviously and possibly taken out because it was specifically
>> needed for systemd and reassigned to BLFS where it resided for the longest
>> time, but these other packages technically are not technically required by
>> LFS. Now, I understand that several packages in LFS such as:
>>
>> tcl
>> check
>> dejagnu
>> expect
>>
>> are used primarily for testing purposes during compiling and are included
>> during the bootstrap phase, and that LFS is not a true minimalist system,
>> but in regards to actual usefulness during the build phase, those
>> forementioned packages are not required on any level even in regards to
>> checking system packages or properly booting the system. In my hint
>> eudev-alt-hint.txt which is now (hopefully temporarily) deprecated, I
>> mentioned these packages could be excluded.
>>
>> I'm not certain of the logic behind leaving these packages in LFS since
>> they technically aren't required for the base system. Not to step on toes
>> or make a ill statement, but because LFS is somewhat of an educational
>> experience, leaving these packages in serves no purpose and no educational
>> benefit (at least in my opinion anyway), and in my own humble opinion,
>> resigning them back to BLFS would be a possible wiser choice because of
>> the
>> lack of necessity to the base.
>>
>> In my own opinion again, the base system should just be that, a workable
>> base with minimal tools, but not the bare minimum (if that makes sense) to
>> get the kernel loaded, the shell activated, and the interface brought up,
>> but with enough usability and the right tools and packages to expand
>> outward.
>>
>
> The reason I left libcap, attr, and acl in LFS is because they are
> security applications useful in any environment, even though they don't
> have to be used.  The reason for gperf, expat, and intltool is because they
> are used in a relatively large number of BLFS packages and I didn't think
> the time or space building them in LFS was significant. XML:Parser was left
> in (actually put back) because it was needed for intltool.
>
> The reason I removed dbus is that it really isn't useful until you have
> completed xorg (unless you are using systemd).
>
> If you really want to cut down on LFS, you can remove autoconf, automake,
> and probably libtool.  They are used less than the packages we just added
> and take longer to build.  You can also substitute joe or nano for vim as
> several distros do by default.
>
> You can (or at least I can) also make a case for adding lsb_release, wget,
> which, sudo, ntp, pci-utils, usb-utils, openssl, and openssh to LFS.
>
> Actually, there is no bright line that can be drawn that says that some
> set of packages belongs and another doesn't.  It comes down to a judgement
> call.  You don't have to agree with my judgement.  I don't mind if you do.
>  Your distro, your rules.
>
>   -- Bruce
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page
>

That clarifies a lot actually. I knew libcap, acl, and attr were centered
around security, but I had always considered that an optional step due to
the setup of acl and attr within fstab, especially since attr and acl are
useful for EXT based file systems but not so much ReiserFS, JFS, or XFS, of
which I've heard they implement internally on some level.

Ive always wondered why pciutils, at least, has never been in the book
since it deals mostly with hardware, but it is somewhat optional. I've
always considered the additions in the Rebooting chapter of LFS as
semi-official LFS packages since Lynx, Wget, and maybe OpenSSL, and
CA-certificates are extremely helpful in progressing into B/LFS, if not
almost required.

I actually have considered nano. I'm used to using vim as it is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20140520/bf14bd99/attachment.html>


More information about the lfs-dev mailing list