Should the build commands be reinstallable?

Matthew Burgess matthew at linuxfromscratch.org
Mon Jan 5 12:41:15 PST 2004


On Mon, 5 Jan 2004 06:25:35 -0500 (EST)
Bill's LFS Login <lfsbill at nospam.dot> wrote:

> On Mon, 5 Jan 2004, Greg Schafer wrote:
> 
> > Hi
> >
> > I know we do take this line in some circumstances, e.g. the
> > coreutils hostname patch, but what about in general?
> >
> > Currently, there is a bunch of packages that fail to reinstall when
> > using the book's commands, mainly due to use of "ln -s" instead of
> > "ln -sf". There's also a couple of "mkdir" 's instead of "mkdir -p"
> > 's as well. And
> 
> I've been doing the above two (ln -sf and mkdir -p). I presume most of
> our audience that script do that also. For those *not* scripting, I
> think the originals (no -f and no -p) are better.
> 
> So the determinant seems to be "who are we talking to?".
> <snip>

Agreed.  Those that script their builds *should* know what they're
doing, and even if they don't they *should* know which docs would help
them get over problems such as `ln` not overwriting an existing file and
`mkdir` erroring when creating an already existing directory.

In the case of the first-time LFSer they should take such output from
those commands as a trigger to think to themselves a) What is the output
really telling me b) Now I understand what/why it's telling me that I
want to learn how to stop it from doing so.

As I've been bitten too many times from my own abuse of `ln -sf` I think
it would be sensible if we steer away from that particular
variation (how many times I'll forget which way around the
"target" and "name" parameters are I'll never know!) - if one gets used
to typing that command it'll be used more often than it's safer `ln -s`
variety IMO.

As far as `mkdir` goes I'm not too fussed either way.  Again,
those that script should know their way out.  Those that are merely
re-installing a package by-the-book shouldn't be that clueless that they
don't understand/remember that the directory already exists and why that
should prevent it's (re-)creation.

I can't remember where we're at with the "prevent multiple installations
of the same binary from different packages" patches but that seems
sensible enough as it even aids users wanting to upgrade to a newer
version of a package without having to re-install another package that
might provide the preferred version of a particular binary.

So, to get to the point (finally!) - I think the status quo is just
fine.

Best regards,

Matt.



More information about the lfs-dev mailing list