Recently, Somebody Somewhere wrote these words
> Unzip is a bit bogus here - you'll need it anyway, for mozilla or
> firefox. But, you really ought to be looking at the current
> development version of the book, which is heading towards a 6.1
> release.
The big reason for doing 6.0 was that 6.0 had the alfs profile. That
worked excellently for me for the lfs bit, but is a waste of effort the
way they do blfs. And I don't want to go to gcc-latest, because
gcc-latest compiles nothing without a patch. Not for a user - why give
himself the hassle?
>
> Compiling everything makes no sense - one of the reasons many of us
> arrived here was because we already have views on which are the best
> packages for our needs. Having said that, with the exception of OOo
> and relational databases (on a desktop ?) I find that 4 Gig (plus a
> separate /home) is more than ample for everything I want.
The database stuff was largely to gain some familiarity - not to start
storing gigabytes of data.
> Yes, but you won't like it :)
> recompile in circles until everything has all features.
>
Ugh! You're right - I didsn't like it.
>
> If you're interested, I'll send you my buildscripts off-list so you
> can see what sequence works for me - the gnome part is even commented
> for where the things I _don't_ build should probably go! But for new
> areas you really need to try building the various alternatives to see
> which you like and which you abhor.
Yes, please send me the buildscripts.
I obviously threw you by mentioning gnome libs. I intend not to have
gnome or kde, but just the libraries to run things like Varicad if the
humour takes me. On the last systems I wouldn't even allow them. So
anything that needed gnome or kde libs was out the window.
>
> The key is to have a reasonable idea of what each package
> contributes, then keep rearranging the pieces until you're happy.
> There are a few circular dependencies in the sense that foo improves
> bar, bar is necessary for baz, and baz can improve the experience of
> foo. Generally, weigh up the merits of what is optional, then make a
> decision about what order you'll use. Very few people will notice
> any deficiencies in these cases.
How do I get a reasonable idea of what each package provides? Fine when
I know and use the thing, but when I don't, I get a line on top of the
BLFS book page and the first sentence of the README. This sort of thing.
---
Introduction to SDL
The Simple DirectMedia Layer (SDL for short) is a cross-platform
library designed to make it easy to write multimedia software, such as
games and emulators.
---
What was that about? It's either invaluable or valueless, and it's FAR
from the worst of them. 12 'Optionals' are listed :-/.
Your scripts don't have a build order set? Better send a README.
BTW, the overwhelming advice I got was to ignore the 'optionals' and
that in most cases I won't miss them. I was anxious to get this right in
the multimedia stuff because compiling --without-something is likely to
hurt more there than when I don't know what things do.
--
With best Regards,
Declan Moriarty.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
