| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On Mon, 2024-11-25 at 03:46 +0000, Ken Moffat wrote:
/* snip */
> 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.
Just use vim and press "/" to see where the regexp part of the sed
matches. If unsure use -i.orig.
> 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.
If using a different version *nothing* in the book is guaranteed to
work, not limited to a fix-up (patch or sed).
Just for making things to work, you may even need to install a new
dependency, fix some bugs introduced by upstream, or adapt a downstream
package for the change, blah blah.
And for making things "perfect", you may need to remove a LC_ALL=C in
test instruction, remove a "CFLAGS=...", remove a configuration option
not valid anymore (meson now rejects an unknown option, but autoconf and
cmake just ignores it so you need to figure it out yourself, and there
are always <option>...</option> things not in the BLFS instruction for
which you may need to try out yourself), remove something from the
dependency list, remove a "the test named bar is known to fail," raise a
dependency from optional to recommended or vice versa, etc.
If we just focus on fix-up:
The worst case of a broken fix-up in BLFS is a patch which *introduced*
a segfault in some package. It was about 10 years ago so I cannot
remember which one, but I'm pretty sure it's a patch, not a sed. I
consider it the worst case because arguably the patch introduced a
security vulnerability non-existing upstream.
The second worst case is "sed -i s/3000/5000/ libxslt/transform.c
doc/xsltproc.{1,xml}" in libxslt instructions, yes it's a sed but
changing it to a patch will do nothing good either, i.e. doing so will
not make us to detect the issue earlier. I consider it the second worst
case because it'd been kept in the book for 5 years (9 releases),
despite it's just useless instead of harmful.
A similar case is "ulimit -s 32768" which had been in LFS (and BLFS) GCC
test instruction: it was doing the correct thing in 2010 but it's no
longer correct since 2011 (here "incorrect" means it was not doing what
our text described, and in 99% cases it was just harmless), and it was
finally fixed in 2024 thus in 13 years we'd kept a broken work around.
It's neither a patch, nor a sed.
So for who *really* cares the development of LFS or BLFS there are
plenty of things to worry about. Changing from sed to patch is not
really so helpful for preventing a human error. And in 99% cases a fix-
up (sed or patch) is either directly taken from upstream, or submitted
to the upstream by one BLFS editor. Thus the editor completely knows
its upstream status, and knows when to remove or update it. The worst
cases of incorrect fix-up are either the remaining 1% case (where we
apply something not even reviewed upstream), or not a code change at all
(like the GCC test suite case).
Who really cares about the development should just be careful. If you
are really developing a package, you should deliberately deviate from
the book, for example you should not ignore compiler warnings. But it
does not mean LFS is wrong, for example the LFS FAQ is not wrong for
telling to ignore compiler warnings when you *build* (instead of
*develop*) a package.
To me the original post is a version control issue. If "brain as the
version control" is not enough you should make use of a version control
tool, like Git. Just extract the source tree and make the initial
commit (or just work in a clone of the upstream repo if you have one or
it's small enough to be cloned as needed), apply the sed and make the
second commit, and make your own fix-up and make the third commit, etc.
But obviously BLFS won't tell you to run "git init ." in a package
directory, nor running "git clone https://example.org/upstream/repo.git"
for fetching the source tree.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page