[blfs-support] Guidance On BLFS Package Dependencies

Ken Moffat zarniwhoop at ntlworld.com
Fri Nov 9 11:05:25 PST 2012

On Fri, Nov 09, 2012 at 06:26:13PM +0000, Feuerbacher, Alan wrote:
> Hi,
> I'm soon going to start building BLFS for the 2nd time -- this time on my new system -- and I'd like some guidance on package dependencies. I'm building the development version of LFS right now.
> The first time around I found by trial and error that most packages have dependencies of some sort, either required or recommended. Some package recommendations turned out to have circular dependencies, such as ghostscript and texlive. Is there a way, short of looking at every package installation page, to find the dependencies so that I can install everything in an efficient manner?

 Probably, but I don't know what it is :)

 In my own case, I build a shed-load of packages before rebooting.
Then, docbook and related packages, followed (on a desktop) by the
parts of xorg that I use or haven't got around to removing from my
build.  After that, I treat it as functional - one script builds the
gtk toolkits and related packages, and allows me to build icewm, the
next builds firefox with *all* the dependencies that I care about
using system versions.  From there on, I think about what is
important and prioritise those packages.

 My last documented build, and some previous desktop versions, are in
~/ken/desktop-builds at lfs.  The few parts of gnome which I use are
still at 3.4.  Since then, the only things I've updated have been
firefox/xulrunner, webkit (1.8), a few libraries (all these for
known vulnerabilities), and gutenprint (for printing changes, I rip
out the whole cups stack, so e.g. cups-filters also got updated in
my rebuild.

> Another thing: The first time around I had only a vague idea of what BLFS packages would be useful to have already installed before I fired up LFS for the first time. The LFS book recommends GPM, Lynx or the equivalent, and Dhcpcd.
> What other BLFS packages would you recommend to make life easier? I have my own ideas about this, having gone through the installation once, but I'd like some advice from experienced people.
 I'm not suggesting that any of these packages will be useful to
you, but they are what I build and for a few of them I explain why I
build them.

 You will notice that I don't build gpm : whenever I'm building a new
system I do the first parts in an xterm or equivalent, and if I get a
new machine I (*horror*) install a backup from a previous machine,
fix up the details such as hostname and fstab, and build a kernel to
suit.  After that I use it to build LFS/BLFS properly.

> The LFS book, in section 9.3, states:
> "Installing a text mode web browser, such as Lynx, you can easily view the BLFS book in one virtual terminal, while building packages in another."
> This assumes that you've installed a terminal program of some sort. What programs work well in a system that does not yet have X installed?

 Someone, possibly you, asked this question recently - when an LFS
box boots, you are in tty1.  Use Alt-Fn to switch between the
different terminals : where n is 1..6.  And Alt-F7 to go back to a
running X desktop if you ever switch to a tty.

> Finally, as I installed certain BLFS programs, I found that a few required certain modules to be installed in the Linux kernel. Is there a good way to figure this out BEFORE compiling the kernel so that I don't have to recompile it several times?

 Again, it was asked recently, I think someone pointed out which
pages mentioned the kernel (it's near the bottom of longindex.html).
Personally, I'm not a believer in uptime on desktops - I use
development kernels a lot, so recompiling to try something new is not
a big deal.

 To be honest, you should work out the first part of what you want to
build, and coming up with an order that seems to work, while you have
a graphical browser.  So, at a minimum xorg, your choice of browser,
and whatever those pull in as dependencies.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the blfs-support mailing list