Re: good patch vs. sed fixes

On Sun, Nov 24, 2024 at 01:18:23PM +0100, Rainer Fiebig wrote:
> 
> - If you apply sed-statements (or other build-instructions) to versions
> other than those they are intended for and the results are not as you
> expect them, that's _your_ problem.

And that is the common case for ALL developers trying out a new
version of a package.

> 
> - If you use a script or build-system which doesn't have safeguards for
> such mistakes, that's again up to _you_ to solve.
> 
> I can't see how any of those should be of general concern.  Neither are
> they a reason to replace sed-statements with patches.  Both have their
> specific use cases.
> 

And specifically, with a patch it is mostly reasonably simple to see
if it applies.  Yes, I am aware of cases, particularly in the
kernel, whare a patch has affected the wrong hunk of a file which
has been changed since the patch was first created, but compare that
to a sed: first you need to work out what is being changed in the
'intended' version by applying the sed and diffing.  Then, you ought
to look at the new code, see if expected code is present, and if so
does the sed fix it, and does it change any other lines.

In many cases, a sed will change other lines which do not matter.
On occasion when I was editing I attempted to limit a sed to only
the desired lines (without specifying line numbers, of course) but
often that was impractical.

For those who are happy to only follow the book, and to assume that
editors do not make mistakes or apply seds which in fact no longer do
anything, none of that is an issue.  But for those who care about
the development of LFS or BLFS it is something to bear in mind as
versions of packages change.

ĸen
-- 
The Soemrset Nog - a cross between a Suffolk Punch and a Dachshund.
It gets very foggy on the moors.
 -- Kenneth Williams as Rambling Syd Rumpo.

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page