Gilles Espinasse wrote:
> From: "Bruce Dubbs" <[email protected]>
>> sed -i '195,213 s/PRIVATE_FUTEX/FUTEX_CLOCK_REALTIME/' \
>> nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timed{rd,wr}lock.S
> I agree that sed could be a gain for simple change that are unlikely to
> break. But breaking for a patch is a feature when code change that could be
> controlled by diff context size and patch --fuzz
>
> What is the gain of a sed expression that need to be checked on upgrade when
> a diff could be made with a larger context and by safer?
> Something like a diff --unified=6 would have more luck to break if code
> change.
The gain is that someone can see at a glance what the changes are.
There is no extra file download. The sed above is really simple because
there are no wildcards or escaped characters. Adding the numerical
addresses also has an educational aspect, which is one of the goals of
the book.
If a user applies a sed like this to a version of the package not in the
book, then it could silently break. Whose responsibility is that?
Hopefully the next version of glibc will have the fix and the sed will
not be required.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
