r7347 - in trunk/BOOK: . introduction/welcome postlfs/editors

Ag. D. Hatzimanikas a.hatzim at gmail.com
Wed Apr 9 11:12:28 PDT 2008


On Wed, Apr 09, at 10:38 Randy McMurchy wrote:
> Ag. D. Hatzimanikas wrote these words on 04/09/08 10:28 CST:
> 
> > I hope I covered the case, as it seemed to me so obvious when I fixed it, 
> > that it didn't deserve a discussion or a ticket.
> 
> I'll be honest in that your explanation was too complicated for me.
> 
> I suppose the only question I have is:
>

> Does it work if we leave it the way the author intended (hard links)?

It does work, yes.
 
> I also notice you don't address the Python situation which is exactly
> the same thing, yet we don't do anything.
> 

I don't have time to look at why Python does this way or zsh for that
matter, but by just guessing (trying to be in the developer mind), maybe
this has to do - first - with the updating procedure and a second reason
could be that, even if you upgrade to a new version, you can still have
the old working version around to use it for any incompatibilities as a
fall back, and that is why they keep a version'ing executable.

As for this specific case with ed, you have my authorization to revert
the commit, but I won't do it because I think this/(that was) the right
thing to do. I have to say in that point, that you have to believe
that I will keep no harm really.
You have the final take on everything and I respect that.

Best regards.

-- 
http://wiki.linuxfromscratch.org/blfs/wiki/Hacking



More information about the blfs-book mailing list