[blfs-support] Best way to build BLFS ?

Marcos Pansani marcos_pansani at yahoo.com.br
Tue Jul 7 19:21:29 PDT 2015

I understand that every part of the book is important, I always try to build "General Libraries", "Graphics and Font Libraries", "General Utilities" in front, but sometimes you need to "System Utilities", "Programming" to resolve dependencies but it is difficult to resolve dependencies between them. I will leave for last "Security" because of dependencies, "Networking Programs", "Networking Utilities", "Networking Libraries" build "Databases" only when a package asks how dependent I do not know if everyone would be required. The maiorsia of "serves" do not interest me because I am a desktop user, only need a package as a dependency, but do not install the BLFS-bootscript. Xorg is one of the last to leave to build. KDE or Gnome is what I leave last. Alias, which I leave for last is the firefox is LibreOffice.

      De: Ken Moffat <zarniwhoop at ntlworld.com>
 Para: blfs-support at lists.linuxfromscratch.org 
 Enviadas: Terça-feira, 7 de Julho de 2015 22:37
 Assunto: Re: [blfs-support] Best way to build BLFS ?
On Tue, Jul 07, 2015 at 11:24:21PM +0000, Marcos Pansani wrote:
> Hello everybody, I am building od BLFS 7.7 and I'm a second thought ....
>  I first compiling packages that have no pending. Then there comes the problem, all other packages have pending as required Dependencies, recommended dependencies and optional dependencies. I have to compile breaking any of them. By importance, ignore the "optional dependencies" and thus solve some dependencies on other packages and then plan to rebuild what I left behind with the "optional dependencies", but even doing this, there is still more packages that have to stop ignoring too "dependencies recommended "to continue to compile other packages, but my fear is that as the compilation was not 100% complete can affect other packages ...
>  I do not know if it was a little confused what I meant, but I wonder how you make to compile with all dependencies, if you compile more than once package ....

First, I suggest that you identify which packages are important to
you, and in general ignore optional dependencies unless you can see
why they would be useful to you.

Also, make notes so that you can avoid problems if/when you do this
again.  My first builds were not especially useful to me - it helps
a lot if you already have some idea what you want to use.

After that, trace the dependencies to make sure you do not omit
anything that you later need - I had to change my own build
sequence to fix up the "build openssl _after_ Python" dependency
in firefox.

Then, I suggest that you take it in stages.  In my own case, I build
a shed-load of packages before I even try to boot the system, partly
to get networking, mail, cron and various other "infrastructure"
working enough for me to use the system (e.g. all my notes are on
nfs).  After that, I build docbook stuff - I'm an editor, it is
convenient for me to build those packages on all my systems, whether
server or desktop.  Then, for a desktop -

1. Xorg - I deviate from the book, some things I omit, in other cases
I add a lot of extras such as decent (TTF/OTF) fonts.  At that point
I can run fluxbox as my wm, which I find usable (unlike twm ;) and
also I build rxvt-unicode (I find regular xterm less than wonderful,
e.g. my vimrc has a section to highlight excess whitespace which
works correctly in urxvt but not in xterm).

At that point, I can put multiple terms on multiple desktops.
Easier than using ttys, but not a great leap forward.

2. Most of what I build uses gtk2 or gtk3, so my next step is to build
those toolkits (but not gobject-introspection), along with most of the
other graphics libs (jpeg, tiff - png is needed for Xorg).  I also
throw in my preferred wm, icewm (needs gtk2) and xscreensaver
(pretty ;-)

3. From there, I prioritise firefox - so, a little from the AV libs,
gstreamer and the *base* plugins, then firefox.  Apart from anything
else, if I do have problems with a package (it happens, I'm trying
new versions of LFS, or new versions of packages), searching google
on firefox is a lot easier than searching on a text browser.

4. After that, I build image-manipulation stuff, things for
printing, dependencies for libreoffice, LO itself (I use 'calc'
spreadsheets even for my notes on what backups I wrote to which
external drive), and only then do I get round to building the main
audio-video libs and the gstreamer plugins so that I can finally
watch youtube.

Alternatively, if I was building a kde desktop I would still build
enough to get firefox working, but I might omit a few things such as
gtk3 and then I would build a very different set of packages.

Thes approaches work for me, but my point is that I have targets
along the way and they give me some sense of "reward" for continuing
with the build (if everything still works).  I very much doubt that
any sequence that suits me will look good to anybody else.

My first BLFS builds had _much_ less on the desktop - modern libre
software has advanced a lot.  I think the only sane way to proceed
is to break the build into bite-sized pieces.

Final thought - the BLFS book is changing all the time.  Unlike
Bruce, I cannot recommend our released versions - they are a nice
record of where we were, but vulnerabilities happen all the time
(firefox now gets a new major version about once a month) and the
dependencies or build instructions change as time goes on.  So, I
suggest you keep a local copy of the development book, and work
from that while you are building a set of packages.  But also keep
an eye on the development book, and the -dev and perhaps the -book
lists (links to the archives are on the website - no need to
subscribe, just get an overview of what is changing and where people
are reporting problems).

This one goes up to eleven!

FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-support/attachments/20150708/6ca5a542/attachment.html>

More information about the blfs-support mailing list