Re: good patch vs. sed fixes

Am 22.11.24 um 00:06 schrieb Uwe Düffert ([email protected] via
blfs-dev Mailing List):
> Hi,
> 
> On Thu, 21 Nov 2024, Xi Ruoyao wrote:
> 
>> On Thu, 2024-11-21 at 03:40 +0100, Uwe Düffert wrote:
>>>
>>> I'm not sure it is worth the effort, but from time to time I stumble
>>> across the "problem" that certain sed or patch commands would apply
>>> multiple times although they should not. I'm fully aware this is
>>> unsupported "deviating from the book" but it happens. I'm trying to
>>> build
>>> some not-yet-in-the-book new version, something fails, I fix the problem
>>> and try again, then some unexpected "double sed" or "double patch"
>>> silently breaks stuff. Sure, I should have done it cleanly from scratch,
>>> but the nature of the fixed problem suggested I could just repeat the
>>> build...
>> Then why not just issue "./mach build"?  Why the sed is ever executed
>> again?
> For some reason, a fresh version of a package does not build with
> original instructions, so I need to modify something. If this was only
> package sources, ./mach build (in case of firefox) would be OK. But
> usually I would have to recompile a dependency or add a patch to my
> build script or add/remove an option and reconfigure, so usually need to
> re-run more then just ./mach build (or the like). My buildscript also
> logs all output which simplifies finding the source of a build failure.
> So there are cases regulary where I'm tempted to just re-run the build
> script, e.g. if configure fails early and that is easily fixable. A
> unified patch usually would not hurt in such sceanrio, in contrast it
> would tell me via "reversed or previous applied patch" that everything
> is as it should. When my firefox build bailed out with a poppler problem
> I already had applied the sed multiple times without being aware and
> would not spot the difference anymore, the line had multiple
> CLASS_CHARACTER instead of one, presumable successfully applied, still
> build broke. I surely tried pure ./mach build a few times at that point,
> because I wanted to identify the cause before starting from scratch
> until I finally noticed what the multi-sed actually did silently.
Sorry, but your approach is wrong.  Instead of entertaining the idea to
adapt the books to the needs and insufficiencies of your build-system or
work-habits, you'd better try the other way round.

I also have a problem with the subject of your post as it seems to
indicate that a patch would generally be superior to a sed-statement.
That would be nonsense.  The seds in the book efficiently and
transparently do what they are intended to do.  The problem rather seems
to be that you do not fully understand how sed works or what the
statements do _before_ you apply them.  Using the seds with "-i.orig" or
"-i.bkp" and then comparing the two files before actually building the
package might be helpful in this respect.  Or use a diff-statement in
your script for that purpose and include the output in the build-log for
later review.

Rainer

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