gmane.linux.lfs.devel

Re: LFS SVN and Systemd Report

Bruce Dubbs — 2012-05-25T13:52:32

It's not clear what that does.  From dmesg, it looks like the kernel is 
till running at 6.7 seconds.  It will take a little longer for the 
kernel to load all those modules.

I don't understand where systemd gets it's numbers.  It


That's not very clear to me.


Better.


cgroups should be optional.  Imposing complexity on simple problems is 
not letting the user decide.


Another case of taking away user choice.


I've asked on the hotplug list, but I havn't received a response.


If you want to build a simple web server with no xorg, why would we need 
dbus?  Another case of imposing a lack of choice.


We use the login from shadow.


   -- Bruce

LFS SVN and Systemd Report

Armin K. — 2012-05-25T12:55:58

Hello there, I have just finished LFS+BLFS SVN (with software from LFS 
Trac too, including Perl 5.16.0, Udev+Systemd 183 and Linux 3.4.0).

I say LFS+BLFS since I installed some BLFS packages during LFS build. I 
did not want to complete everything and then install BLFS packages and 
possibly recompile some of LFS packages. But, never the less. Everything 
works. Also, I ditched sysklogd and used rsyslog for my system since it 
provides native systemd units.

I want to add that I've experimented with "the /usr merge" since I use 
one partition for everything.

$ uname -a
Linux lfs 3.4.0-krejzi #1 SMP Thu May 24 18:33:15 CEST 2012 i686 GNU/Linux

My hardware is an older Pentium 4 HT with 1024MB of DDR RAM.

After booting with basic software installed, I get
$ systemd-analyze
Startup finished in 1686ms (kernel) + 7995ms (userspace) = 9682ms

Currently running services are
http://paste.debian.net/plainh/14ddd735

Or if you prefer as ps output
http://paste.debian.net/plainh/504f9d4c

Memory usage with such services is as following
$ free -m
              total       used       free     shared    buffers     cached
Mem:          1007         25        981          0          0          6
-/+ buffers/cache:         18        989
Swap:         1080          0       1080

with lot of modules as shown here
http://paste.debian.net/plainh/ea7237d9

I saw that someone complained about mount output on some other systemd 
distro. Here is mount output from my installation. I needed to remove 
some useless mounts that I did not need like debugfs and such.
http://paste.debian.net/plainh/aa83f0f6

securityfs seems to be hardcoded into systemd binary. Others are cgroups 
which expose like that. Also, /tmp can be set not to use tmpfs if desired.

Since I don't even install LFS bootscripts package, I don't have any 
networking with systemd. But that one is simple ... Just executing 
dhclient eth0 brings up my interface. Also, I have created /etc/rc.local 
for local scripts so I could run some scripts from there at startup. 
(Found in Debian too).

If you are interested, here is dmesg output
http://paste.debian.net/plainh/5316e589

I don't have any build stats or such stuff, I needed 3 days to build 
everything, but with taking notes, making patches so I can install 
everything how I want with just one command.

So, is LFS still going to avoid systemd? I said on trac that it is not 
possible to install just udev from systemd tarball.

I've also discovered that udevd is now named systemd-udevd and located 
in /usr/lib/systemd (or /lib/systemd/ if not using /usr merge like me).

systemd also manages configuration of locale (/etc/locale.conf), 
timezone (/etc/timezone), hostname (/etc/hostname) keyboard and console 
settings (/etc/vconsole.conf). Note that vconsole setup is broken in 
default systemd installation since it starts before KMS and KMS resets 
console font and charset. I've hacked on it and set it to start after 
tty's have been spawned.

Regarding the dependencies, I've discovered that the following are minimal:

attr and libcap
expat and dbus
xml::parser and intltool

Also, if intended to use systemd-logind as consolekit replacement, 
linux-pam is necesary for pam_systemd.so.

Other deps are tcp wrappers (no idea), cryptsetup (for accessing 
encrypted volumes), selinux and audit (no use on lfs anyways, I've 
stopped using it).

Your move.

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-23T02:18:26

Actually, from my experience a packaging tool eases a lot of the pain 
inherent in the process you've described. Auto-fetching of sources 
(including dependencies), auto-preparation of a clean build tree, 
post-build reports of what files have been included in the package and 
what (if any) auto dependencies have been discovered.

Re-doing a build if issues or errors are found (including, if necessary, 
setting up an entire chroot system as well) becomes a matter of one 
command, instead of several.


This is one of those scenarios where I think it's difficult to see how a 
thing will be useful or beneficial until after you've actually tried it 
out. I'm not guaranteeing you'll think it better, more useful or simpler 
- though my belief is that it does actually simplify the process of 
correctly building and documenting the build of an individual package, 
once the tools are available and the infrastructure in place.


Perhaps it really is something that needs to been seen and experienced. 
I can do as I planned and document the procedure to build in PM with LFS 
and set up the basic infrastructure required (a web server with a public 
binary repo). Once that's in place, anyone who wants to test out the new 
workflow can try it and offer thoughts, comments, suggestions. Then 
perhaps a decision can be reached as to whether it be actually 
implemented for either LFS or BLFS. This way, too, at least the 
documentation will have been done.

Anyone interested in helping with the above, or should I just report 
back here when I've accomplished this on my own?


This is a great question, and I'm still not sure the best way to answer 
it. Perhaps it should be tabled and reconsidered if and when either book 
looks to actually adopt the workflow as 'official'.

JH

About packaging LFS - How it works for me 8)

Marius Tolzmann — 2012-05-23T00:00:52

Hi..

I was pointed to the "Once More: Package Management" discussion 
yesterday. So I just joined this list.

First I want to thank you for LFS. It's great. I love it. And i made a 
few more people love it, too. The same is true for BLFS.

I will start with many words about my LFS background 8)

I am using (B)LFS (as a reference) since (i think) 2004. After we had 
some serious issues adjusting a red hat linux to our needs I started a 
linux from scratch to finally have a linux that follow my rules 8)

I really learned a lot from this documentation - even if it wasn't very 
easy all the time.

When using an LFS based distribution in a production environment you 
have to do some kind of minimalistig package management. what we do and 
what we have done isn't really package management it is more about 
package tracking - to answer the important questions like which file 
belongs to which package? just to be able to install and remove a binary 
package after creating it following the (B)LFS Book(s).

Two years ago we were forced to rebuild the whole system - because it 
seemed to be easier to rebuild than to upgrade and solve the dependency 
hell.
The way we maintained our LFS based system between 2004 and 2012 worked 
wuite well, but was not really perfect: To document how a package was 
build we just scripted the steps to build it and executed the script, 
did some binary package creation and just kept the directory of the 
build as documentation. Our documentation was quite bad these days.
So when starting to rebuild our LFS based system I decided to do it 
better this time. I tried to find some package management software which 
was very easy to use, is highly configurable and helps me to document 
the build - just to make updating and rebuilding packages easier for us 
- Long Story short: I havn't found a package manager.

But lazy as I am, I started scripting some code together to help us to 
maintain the system. The goal was easy: 90% of the software is configure 
&& make && make install. some special options here - some patches there 
- some post install issues in some packages.
All those special options don't change much from one version of a 
package to another. So Reusing build-scripts was a main goal.
Since we are LFS based we want to stay as close to (B)LFS as possible.
So just cut & paste the LFS recipies would be great for us. After taking 
some time to think about our needs we started to implement something. 
The idea was to first have a solution for the easiest case:
configure && make && make install - no options, perfect software with 
perfect defaults - so we implemented something for the perfect world. 
And step by step we were forced to face reality and add more flexibility.

After Two years we have managed to have a working LFS based system - 
build with our own package system - which is used in production on many 
big servers and many workstations now.

So much for the background and our ideas. We just released our first 
official version of our tool to manage packages in our LFS based 
environment. I will not call this tool a package manager because it 
lacks some important features to call it so but i think it may be 
interesting for some of you to know it exists. It is not perfect - even 
it tries to be perfect so hardly - and it may have some (minor) bugs but 
it works (at least for us).

The name of our tool is BEE - an acronym for "bau et einfach" (which is 
german for "just build it" but it may also be an acronym for "build 
extremely easy".

What BEE can do:

In it's easiest form it can build a binary package directly from an URL 
pointing to a source tarball. And that is already the main feature. The 
user just has to know the URL. We tried, but we haven't found an easier 
way to create a binary package out of source tarballs.

bee binary packages are tarballs.. no fancy format..

Yes, this works for autoconf based sources and for cmake based sources 
and for perl modules and ... it just works.. it autodetects a lot of stuff.

And yes, you still have the possibility to change every single step in 
the build process. All BEE does is to create an initial (so called) 
bee-file which provides a basic structure of a generic build process.
(In fact it creates a script (bash) which has a lot of comments and just 
sets one variable: the SRCURL).

You can just add some shell functions to overwrite/expand the 
autodetected defaults with your own idea of how to configure the 
package, build the package, patch it or whatever.

Short: you can influence nearly every step bee does.

So it is easy to create bee-files for LFS packages that are in my 
opinion quiet close to what is described in the LFS book.

We already started a small proof-of-concept project where we provide 
some bee-files for the LFS chapter05 toolchain (the other chapters will 
follow when we find some time)

Why i don't want to call it package management:
You can install the binary packages you can update them or remove
them from your installation. Which is in fact some kind of management.

We don't provide support for remote repositories where you can get 
binary packages from. It is more intended to work as follows: You create 
a bee-file, you build your package, and you install it.
Local build, local package repository (some directory), local installation.

We don't provide config-file management (yet). We have some (cool) ideas 
how to solve this issue without loosing our main feature:
URL -> PKG.

But we don't provide any automated dependency resolution. And we don't 
plan to do this in the future.

But we plan to provide some information which can be automatically 
generated at buildtime about what packages the current package was built 
against. How the new package may break already installed packages.

We just don't have a solution how to fix the dependency hell without 
getting crazy. In my opinion, everything which needs to be done manually 
when trying to provide information about how to resolve dependencies 
will fail.

And we also don't support build-time-dependencies at all. Because there 
is nothing a test for the availability of build-time-dependencies can 
tell you what a failing configure can't tell you better. (And even 
worse: if a configure does not fail, it does not mean that all build 
time dependencies are satisfied - the make may fail later 8) )
Perhaps nobody will ever solve this - we don't try.

Ok... this is a very large first post.. 8) sorry for that.

just some quick bee examples:

the bee file for LFS chapter 5.4: binutils pass1 [1]:
   (comments and some other stuff removed, original file in [2])

Re: Once more: Package Management

Pierre Labastie — 2012-05-22T06:46:13

Le 22/05/2012 01:58, Armin K. a écrit :
Hi,
It depends on what you want to do with a package manager. I would 
separate two main uses :
(a) Building from sources using a spec file.
(b) Packaging and installing.

As far as (B)LFS is concerned, (a) involves some kind of rewriting of 
the book instructions to make a spec file. I do not know whether it is 
the purpose of (B)LFS to show how to do that. Among the PM I know 
(mainly dpkg and pacman), pacman is by far the easiest for this purpose. 
The spec files used by Bent linux were very simple too, but the project 
seems to have been stale for a few years. I agree that dpkg is more work 
to learn, but at least it is Makefile instructions, not a completely new 
language as rpm.

If the only aim is to do (b), and I would believe that it is what is 
needed by (B)LFS, dpkg is by far the simplest: it amounts to build per 
the book instructions adding DESTDIR to the install commands, making a 
very simple description file (sample below), and running dpkg-deb then 
dpkg -i. Even Pacman is slightly more complicated, because (a) and (b) 
are not well separated. The advantage is that the PM warns you about 
overwritten files, and you can uninstall with just one command.

Sample of the description file for gcc in chapter 6 of LFS:

-----------------------------
cd $DESTDIR

mkdir -v DEBIAN

cat > DEBIAN/control << EOF

Package: gcc-lfs

Version: 4.4.3

Architecture: i386

Maintainer: Pierre Labastie <lnimbus< at >club-internet.fr>

Depends: mpfr

Provides: gcc, g++

Description: GNU compiler collection (C and C++)

This package is the LFS installation of the GNU compiler collection, 
which contains only

C and C++. You need to install gcc-blfs for the other compilers.

EOF

------------------------------
Only five lines are mandatory:
Package, Version, Architecture, Maintainer, Description. Depends and 
Provides are of course rather useful. It can be made (slightly or much) 
more sophisticated, regarding the post installation instructions and the 
management of config files. This is the same for other PMs. Those 
sophistications are not really needed for (B)LFS, IMHO.

Regards
Pierre

Re: Once more: Package Management

Armin K. — 2012-05-21T23:58:38

I don't get what's the whole thing about, but I think that packaging can 
be documented very well. I have installed about 1000 packages using 
DESTDIR or equivalent method, writing base INSTALL files which contain 
just cp -r commands and some triggers, like adding an user, chowning, 
chmoding, running gtk-update-icon-cache, man-db update, installing info 
files and such. It's not hard work and it can be done if we just put 
some effort. Also, if this is to happen, I suggest we don't make any 
changes to the current BLFS since Bruce has planed release for 
September, and it isn't enough time for the goal. I am in process of 
fully documenting build process from cd sourcedir to after make install 
DESTDIR, including install triggers, post make install stuff like 
stripping, creating aditional files, symlinks and such.

Also, I see you mention package managers ... For me, Debian's dpkg is 
the hardest one. debian/rules file uses Makefile syntax which I am not 
familiar with. Red Hat's rpm uses some kind of spec file which doesn't 
seem that hard to understand, but still it's medium-hard for newbies and 
for me, too. Gentoo's portage is difficult like hell, I never even 
bothered to look at one of it's files. Archlinux's pacman seems most 
easiest. It uses bash syntax, it's just like LFS "input" commands are 
pasted into that file. So, if you people decide to "make book generate 
spec files", go for pacman, it will be the most easiest to implement.

Sure there are more, but theese are most common ones mentioned.

Re: Once more: Package Management

DJ Lucas — 2012-05-21T23:27:12

Seems my phone ate my previous response...easier to type on a real 
keyboard anyway.

It omits the core point of LFS...education. I dislike providing binary 
packages to users, but a working example of how to create those binary 
packages is something we've lacked for a long time, plus getting those 
packages that don't honor DESTDIR explained with a working example 
chroot...I just can't (or possibly don't want to) see a downside as far 
as education or documentation is concerned. Yes, it'll undoubtedly be a 
bit hairy at first. As far as choosing what PM to use, I guess it is no 
different than making the decision to use vim over emacs (an equally 
nasty holy war). As long as concepts learned are applicable to other 
PMs, then it is all good. I suspect a good deal could be taken from 
other consumers of pacman (that is what Arch uses, right?).

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-21T01:10:52

[snip - a number of good, thoughtful questions]

I'm going to have to let your questions brew for a while before I can 
reply to them. Perhaps someone else will have an opinion regarding them 
in the meantime...

JH

Re: Vim 7.3.xxx

Bruce Dubbs — 2012-05-21T01:10:04



OK, I will reorder the patch to be first.


I'll fix this in a couple of minutes too.

Thanks for the feedback.

   -- Bruce

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-21T01:05:56

This method does not collect and keep package dependency. Using a 
manager like pacman, ff you have a repository with dependency baked in, 
when you go to build an individual tool you can automatically discover 
and download/install into your build environment all required packages - 
and only the required packages.

Also, for a reader who is serious about making a distro, creating a 
giant tarball of the LFS base does not teach any good practices for 
creating and deploying a distribution of their own.

Another benefit of a package manager is that changelog information can 
be related to individual packages and can be easier to track changes - 
again, this is less important in LFS, but could be useful in BLFS.

If it's simplicity that you like, one advantage of pacman is that the 
packages themselves are actually just tar archives containing the files 
and metadata.

JH

Re: Once more: Package Management

Baho Utot — 2012-05-21T00:57:50

[putolin]



Just use the dependencies that are required that's in the book.  You as 
a "user/builder can add any additional one you would like.


pacman package management also has a set of tools to check the resulting 
package for "corectness" based upon LSB.  It will also detect permission 
problems and RPATH issues.


One doesn't need to fetch a binary, just the PKGBUILD file and then you 
can build it


I have placed my build of LFS 6.8 using Arch linux pacman package 
manager onto github.

The URL: github.com/baho-utot/LFS-pacman

Have a look at it if you like.

I don't follow the recent comments at all.
Pacman packeage manager has some great features that makes rooling your 
own easier.
For example if I get the PKGBUILD for a package that is in BLFS from 
someone then I am not duplicating my effort and I have a mecanisim that 
gives me a "package that will work".

Package management is also learned so why not include something in the book?

I see using pacman package management as a plus.

Re: Vim 7.3.xxx

Fernando de Oliveira — 2012-05-20T23:21:25

[...]


Just did it. Thank you very much, Bruce. How fast!

Couple of observations:

1. When scripting, if patch is after the echo's, some fail, script stops.
patching file src/feature.h
Hunk #4 FAILED at 1316.
1 out of 4 hunks FAILED -- saving rejects to file src/feature.h.rej

Fine if patch is before echo's.

2. Broken
http://www2.nl.vim.org/unix/vim-7.3.tar.bz2
http://www2.nl.vim.org/extra/vim-7.2-lang.tar.gz

These work
ftp://ftp.vim.org/pub/vim/unix/vim-7.3.tar.bz2 (this already in both books)
ftp://ftp.vim.org/pub/vim/extra/vim-7.2-lang.tar.gz

3. In BLFS:

typo: tar -xf ../vim-7.3-lang.tar.gz --strip-components=1

s/3/2/

Re: Once more: Package Management

Ken Moffat — 2012-05-20T23:09:49

 The more I think about this, the less happy I am.  Point 2 doesn't
really help editing BLFS as far as I can see (upgrading a package
usually needs several builds - typically, for me, a first to see if
it actually works when I use it, then others to get nice clean
measurements, check what is in the DESTDIR (or INSTALLROOT), and
review options for the optional dependencies and any testsuite.

 OK, for a few packages I will build them without being able to
confirm that they still work (e.g. mutt in the recent tagging), but
in general the absence of required dependencies is the least of the
issues - and anyway, sometimes the dependencies need to be upgraded.

 Then there is the question of dependencies - in BLFS we don't
normally tell people how to use optional deps.  Sometimes they are
picked up automatically, but many times you have to pass a switch to
get them used.  The instructions in BLFS are hopefully correct, but
they don't suit everyone.

 I'm also wary of standard workflows - my own LFS build is different
enough (nothing updated in /sources, because that is an nfs mount on
my systems, and with efforts to remove many of the static libraries)
that I expect pain.  And that's just for LFS.  For BLFS, I suspect
this sort of change will actually increase my workload and therefore
reduce my contributions.

 Indeed.  For BLFS, I'm typically now building on both the last LFS
release, and also on a more recent svn version to make sure that
when I say it builds and works with 7.1 it does, and to detect if
any change in a newer LFS package has broken something along the way
(nothing recent, but I can remember pain in a package from a grep
update: something to do with manpages in a docbook package, I think,
which only bit me some time later because I hadn't been building
whichever package it was, and also problems caused by newer kernel
headers).

 The intention is good, but I'm not at all convinced that the plan
will help.

 Also, can I really trust whoever is permitted to edit a book (I'm
assuming that part of the aim is to get more people editing in BLFS
?) to have an uncompromised system, and to not want to upload
compromised binaries ?  For the xml in the book, and for patches, we
can look at what is being changed.  For a binary, how do we know
what was done to it ?  Distros have build machines with restricted
access and some degree of security.  Is LFS going to need signed
binaries and a ring of trust ?

 If I upload an unsigned binary package, the only way you can verify
it is by following the build instructions and seeing if you get the
same result.  I gave up 'farce' testing (seeing if binaries were the
same after an LFS system built itself) because there were too many
inexplicable differences, probably caused by randomisation of
addresses.  Posts in the last few months have suggested that this
problem is no longer present, but don't understimate the difficulties
of trying to see if my binary build matches yours using the same
instructions and the same versions of everything.

ĸen

Re: Once more: Package Management

Qrux — 2012-05-20T23:05:29

On May 20, 2012, at 1:58 PM, Jeremy Huntwork wrote:


Couldn't agree more.

For instance, SuSE wants Xorg for python, which I only needed for Xen.


Couldn't agree more with this, too.

I don't feel it's conflicting to have a system where you can take LFS a a base, and then build on top of it.

This situation seems to really speak to git, where it's easier to branch off--and to decentralize, because any project based on LFS obviously still needs the "trunk", but would allow "addons"--stuff like JH's sysroot build and also the current package management concepts--to get explored, without always sounding the alarm bells of whether or not it's violating the book.


Totally agree here.  I think people are seeing LFS "addons" as being in conflict with the book, and that's probably not the case.

The issue seems to be that there's no way for people to build "addons" with either centralized control (official repo signoff) or distributed development (fork it, because it's not a big deal to fork).

Q

Re: Once more: Package Management

Ken Moffat — 2012-05-20T22:17:50

 Maybe license incompatabilites - one of the great things about
building from source is that we can just build without having to
worry about the details of some of the licenses when thay apply to
binaries.  We can also hack, or patch, the source - compare
iceweasel and icedove to their upstreams.  We used to warn about the
limitations of --enable-official-branding in firefox, but we seem to
have lost that.

 I don't have an example, because I've never had to worry about this
since I stopped providing a RescueCD, but I'm fairly sure there are
packages which will require certain documentation to be installed.
Maybe BLFS already installs it, maybe it doesn't, but it's another
thing that would need to be checked if we were providing binary
packages.

ĸen

Re: Once more: Package Management

Bruce Dubbs — 2012-05-20T21:34:11

OK, then what's wrong with a tarball of binaries that we have created 
for this purpose?  There could be a tarball of the base LFS system and 
then additional tarballs for certain packages or groups (e.g. xorg) of 
packages.

   -- Bruce

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-20T21:08:32

Yes - I believe you have hit exactly what I'm trying to propose. The 
binaries (and binary repository) aren't advertised in any way for 
general use - they aren't even mentioned in the build instructions.

For example, consider this as a very simplified version of a package page:

"Build package Blah:
    Manually:
      ./configure ...
      make

    (Optionally, via package tool):
      # Grab generated spec file here...
      ./makepkg
"

And then the spec file, would have references to the dependency packages 
in BLFS, calling them exactly how they've been referenced in the book's 
source. I suppose here the 'optional' ones could be enabled or disabled 
by a reader. As would devs - although I think for dev purposes it might 
be useful to have built binaries with all optional dependencies enabled.

Behind the scenes, a set of tools and a defined workflow can help the 
devs to share binaries already produced via the spec files - but those 
are never explicitly shared or brought to the attention of the reader.

JH

Re: Once more: Package Management

Jeremy Huntwork — 2012-05-20T20:58:06

I think perhaps the point is being missed here. The purpose of the 
proposal (creating and providing binaries) isn't for the _reader's_ use, 
(if someone found them and wanted to use them that's their decision), 
but it's solely for making development easier and providing 
documentation on how to use a packaging tool for creating an actual 
distribution.

So there is no threat here to what LFS or BLFS currently is. I 
absolutely agree that choice of optional dependencies should be left 
completely to user discretion.

A decision about how to build a binary (and provide a spec file) for use 
by other developers should be based completely, then, on what is useful 
for developing BLFS.

JH

Re: Once more: Package Management

Bruce Dubbs — 2012-05-20T19:10:38

I agree with this.  I am updating vim in BLFS to add current patches and 
do not like all the xorg dependencies in vim.  Others may want gvim.

There are a lot of decisions that must be made in BLFS about 
dependencies.  It's difficult to provide a package manager that does not 
take away the user's choices.

   -- Bruce

Re: Vim 7.3.xxx

Bruce Dubbs — 2012-05-20T18:41:16

You can try:

http://www.linuxfromscratch.org/patches/downloads/vim/vim-7.3-fixes-524.patch 


Apply with:

patch -Np1 -i ../vim-7.3-fixes-524.patch

and then build normally.

   -- Bruce

Re: Once more: Package Management

Bryan Kadzban — 2012-05-20T18:18:22

FWIW...

DJ Lucas wrote:

This exact reason, for the record, is why I really dislike binary
distros.  I *never* choose the same set of dependencies that are
optional in the source, as the distro does.  And because when they ran
./configure, they added a --with-foo flag, the package compiled with
-lfoo, meaning the binary version of the package now has a hardcoded
requirement for libfoo.so.N or whatever it is.

For example, python and bluez.  I don't want an entire bluetooth stack.
 But some distros' python packages require that stack in order to run.
For another example, gtk+ (both 2 and 3), or chrome, or firefox, and
CUPS: I don't want an entire printserver stack (since I only have a
single printer, and only use it from one machine).  Or xine-lib and ...
well, any half of its dependencies, depending on what you're going to
use it to play.  :-)

Now I should say that I don't think this necessarily applies to BLFS,
except inasmuch as testing with or without some of the optional
dependencies might require changes to the package in question.  (If the
CUPS-less version of FF needs some other configuration different from
the FF-with-CUPS binary, for instance.  I don't think that's the case
today at least.)  OTOH when building a system I can probably figure that
out, too.


Perhaps it makes more sense to just keep ALFS the way it is, and not
build packages?  I *know* that I won't be building any package-ish thing
for my systems at all; I'm still using an oldish version of MSB's
package-user setup, so none of this applies.

In other words, I think it'd help to only use packages to simplify
(mostly BLFS) testing, but make them semi-public for people who really
want them.  Don't use them at all in the actual build instructions (what
would be the point?  :-) ), but generate the spec files, or whatever
equivalent, from the book XML.  (This last bit might be either hard or
impossible; I don't know.)