[Clfs-support] Coreutils-6.12: help2man error

[Hugo Villeneuve]

On Sat, 13 Sep 2008 17:15:50 -0500
<wwh04660 at ucmo.edu> wrote:

> 
> On Sep 13, 2008, at 4:52 PM, Hugo Villeneuve wrote:
> >
> >
> > I have a suggestion for the patches:
> >
> > I'm building my clfs system from my own automated scripts. When I
> > install a package, any patches that fix bugs or add missing
> > functionality for that package are automatically applied. The
> > scripts look for any file that start with the package name followed
> > by a dash and the ".patch" extension. If some patches are optional,
> > like glibc libgcc_eh patch, I prefix them with "option_" like this:
> > option_glibc-2.7-libgcc_eh-1.patch and them I manually apply the  
> > patch.
> >
> > Thus, patches handling is easier since I don't have some patches  
> > that I
> > apply to build the cross tools, then some different patches to apply
> > when I build the temporary filesystem, and then another different
> > set of patches to apply when I build the final system.
> >
> > Hugo V.
> 
> Hugo,
> 
>    Well, your scripts should apply patches not based on the name,
> but based
> when the patches should be supplied.

It depends on your philosophy. My scripts have been built with the
philosophy that any bug fix should always be automatically applied,
whatever section you are in. It simplifies my scripts.

> You can dump all the commands
> if you download the book and run make dump-commands. Otherwise, your
> scripts need to be separated for each section.

Of course, some packages have different options depending on the
section, whatever system you use.

> Changing patch names is not our
> part and will
> not be done for people who don't want to take the time to build
> proper scripts.

I have taken the time to build proper scripts, hence my suggestion.

> Patches are not optional in some parts. Do you understand what I mean?
> The patches aren't optional in some sections. They will be required
> in some sections.

That is why I name those patches starting with "option_"

Hugo V.