changes for consolidation

Reinhard bookreader at gmx.com
Tue Mar 16 10:17:57 PST 2004


Thank you for your comment, Matthias.

On Tuesday 16 March 2004 14:25, Matthias Benkmann wrote:
> On Tue, 16 Mar 2004 12:58:08 +0100 Reinhard <bookreader at gmx.com> wrote:
> > I don't know, whether you agree on this:
> > If configure checks the system and the build will succeed without a
> > package, this package is optional.
>
> I think this makes sense, but I would weaken it to:
> If the build succeeds in absence of package X with the book's build
> instructions OR the book informs the user about an extra option to make it
> succeed in absence of package X, then package X is optional.

Following this "weakness" a scanner will never have a chance to do it right.
I don't like the idea to have an additional knowlegde-base beside the book.
And I don't like a system, wich is ok by occasion.

With LFS, I build all packages step by step with the book.
I logged all my actions and builded a Makefile from that.
When I was done, I formatted the partition and started again after chapter 5.
This time using the Makefile.
It was a hard way, but know I have a system, which could be build without  
interaction thus given the same result any time I make up my mind to start 
again.

My aim was to reach the same (system-)quality with blfs.

So what is wrong, with the dependencies reflecting the install-instruction 
from the book? 
Thus making XFree86 required for ffmpeg and mention it in the option 
description, that the package could be build without XFree86 by providing 
--disable-ffplay and for so leave the recommended path of the book.

The book implies, that you build XFree86 before installing ffmpeg.
I would appreciate it a lot, if such implies where not to find between the 
lines.

Well, after all - it's my opinion. Call me pedantic. 
I could not find any harm, if you change the dependencies to conform to the 
build-instructions from the book. 
And the benefit ... I mentioned it yet.

Could it be, that this benefit is not wanted?


Kind regards

Reinhard




More information about the blfs-dev mailing list