xorg build

Ken Moffat ken at linuxfromscratch.org
Sun Nov 9 14:51:56 PST 2008

On Sun, Nov 09, 2008 at 04:02:46PM -0600, Ralph Porter wrote:
> Thanks DJ,
> That leads to another question I guess.
> I just finished LFS, so, now what next?

 I'm not DJ, but I'll answer anyway: whatever you want ;-)
... I assume you mean you've just finished xorg-7.2, so this will
just be a desktop system.
> I think I want KDE and firefox next.  But what should really come  
> next?  I'm using this as learning tool, so working in command mode  
> seems to lengthen that process.

 For people using LFS-6.3, if what you want is in the BLFS-6.3 book,
all you have to do is work out the dependencies ;-)

 A few things which I build early, and which you might want to
consider: alsa, cd/dvd software [ for writing *data* - I use
dvdrtools which isn't in the book (forked from the last GPL's
cddrtools, much easier to build on other architectures and
multilib), but on x86 you should probably stick with cdrecord ] and
dvd+rw-tools ], fcron, ncftp, which.

 I assume you now have a windowmanager you can use for the moment
(with xterm or something nicer), so it's just a matter of finding a
reasonably-sensible order in which to build everything.  If you're a
kde user, for 3.5 you can just work back from the dependencies in the
book.  Same for firefox-2.  If in doubt, most things will work fine
across the major versions, so the latest firefox-2.0.0.x should drop
in fine, as will kde-3.5.latest.

 The first step is to identify the dependencies, then identify
dependencies for their dependencies, and so on.  If something is
"required" or "recommended", you probably want it.  Doing this from
the host system is a lot nicer than trying to do it from lynx!

 In my own case, I make a basic plan of "general libraries and
utilities", xorg, toolkits [qt for kde, glib,gtk,atk,pango and now
cairo for qtk things], my preferred windowmanager (it uses gtk),
more useful things (printing and the gimp), basic audio/video (if the
machine is connected to speakers), whatever I use from gnome, kde.

 I do that in 6 scripts now, but some of them are overlong, and in
each one the order changes as new releases bring extra dependencies
or things occasionally drop out.

 Summary: spend some time thinking about the detail of what you
> On the subject of package managers.  Do I want to go there now, later  
> or what?

 You do need to know what you are installing, so that you can (mostly)
identify where something came from (my preferred solution of listing
new files misses a few headers, but it works adequately for me).

 You also need to know *what* you have installed, because you are
now your own security manager, responsible for monitoring
vulnerabilities and deciding if you think you need to address them
:-(  Keeping build logs is useful IMHO.  Examining them is better (I
don't do that often enough).

> Obviously (or at least to me) yum would be the best choice.  What is  
> your thoughts?
> Packager manager, yes, no?
 Personally, the vagaries of using package managers (back in the
days when 'mandrake' was a little more bleeding edge than 'red hat',
and better optimized for my k6 [i586] that needed all the help it
could get) were one of the things that drove me to building from

 But, I've known people make sensible use of package managers - the
general rule seems to be that they build once to install on more
than one system (with the same architecture, obviously).

 What do you think that yum will give *you*, now that you know how to
build from source ?  In general, anything distributed as a binary
depends on the decisions made by its packager.  The same is also
true of source rpms.  So, you or I can build 'foo' with
'--disable-bar', but a packager may do it differently.

 I certainly wouldn't be without an rpm2cpio script, and google
(with a graphical browser!) to use when I've got problems building
things, but I don't see the point of traditional packaging tools for
those of us who build from source.

 But, it's all about what works for you - ISTR Randy uses some
package management system which identified files being overwritten
by something else in the base LFS system, which I certainly hadn't
known about.

 In the meantime, please don't top post, and trim your replies.

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

More information about the lfs-support mailing list