3 new bug patches for bash2.05b

Bill's LFS Login lfsbill at wlmcs.com
Tue Jun 3 12:30:35 PDT 2003


On Tue, 3 Jun 2003, Gerard Beekmans wrote:

> On June 2, 2003 09:09 pm, you wrote:
> > I think for consistency we should use the "official" patches, do we really
> ><snip>

> This raises another question:
> the book can contain 7 patch commands, or a construction like:
>
> for patchfile in ../bash-2.05b*patch; do
> 	patch -Np1 -i $patchfile
> done
>
> Certainly less to type, and I expect the majority of people apply all patches,
> especially when it comes to the official patches by maintainers themselves.

I see only two issues of any substance. The loop applies the patches it
finds regardless if the user intended to apply them all or not. If
patches are there that should not be, or are not there that should be,
the user does not get any hint of the problem until very much later in
the LFS build process.

Also, it eliminates the reinforcement that comes with seeing the items
listed and explained in the book and then referenced in the code the
user enters (or scripts).

The potential benefit of intro to the for loop is unneeded for
experienced users (they'll probably rool their own regardless of the
presence in the book of this example) and likely wasted (too soon) for
true n00bs.

> But, if we do the 7 separate commands, we have a nice chance to actuallly
> expain what the patches do. It's temporary educational value (they'[ll be
> removed with the next bash upgrade), but valuable nonetheless.

I think that is quite valuable.

> In light of that, I would say going the multi patch command route is more in
> line with what the LFS book tries to accomplish of course. But that should
> always be evaluated within reason, hence this email. Comment if you have
> something useful to add.

Agree, for the reasons I mentioned.

>
>

-- 
Bill Maltby
lfsbill at wlmcs.com
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list