Follow-up Comment #15, bug #33034 (project make):
David Boyce wrote:
> I agree with some of your points but there was a bit of cherrypicking
involved in the quoting:
>
> > ... really, what's the chance a trivial one-line change to the top-level
makefile will actually break your driver?
>
> I'm not sure you realize the scale here. It's not a change to just the
top-level makefile, the pattern is repeated in a number of makefiles.
I was just going with was was said in the bug report. The "workaround" in
comment #2 is indeed a trivial one-line change. If that's not all, this wasn't
mentioned before, sorry.
To me this seems a great example of bad bug reporting:
- The original report and workaround make it look like a trivial issue.
- The explanation for the change (quoted in comment #3) was ignored (see
comment #5).
- The whole issue was ignored for 2 years, just until the next major release
which is just about the worst time to reinstate old behaviour for bugward
compatibility.
> A quick find shows 1360 makefiles in a typical Linux (2.6.36) kernel
Fun fact: A quick find shows over 500000 files on my hard disk!
(Which is just as relevant to the issue; according to the git history search
Josh recommended, it seems to be 3, in words three, affected Makefiles, two of
them in arch, so possibly not even relevant to you. Over-inflating numbers
doesn't help.)
> At least in our case, because these are so large and (supposed to be)
unchanging we haven't stored them in version control; they're in flat file
space aka NFS. With this many files to fix it would be necessary to write a
program which could reliably find all mixed rule lines and fix them right the
first time. The fact that they're not version controlled makes the stakes
higher.
Though I see that it can be a problem for you, I think "higher stakes" is
another exaggeration. It can't be too difficult to back up the changed
makefiles, even without source control.
> > I don't suppose Paul would accept a patch that just reinstates the old
behaviour without fixing it.)
>
> Of course not, that's been made quite clear and it makes sense. But what you
left out from my comment was the question of whether it could be optionally
unfixed at runtime. We all get that the old behavior was broken, but this
happens to be a case where preserving bug-for-bug compatibility is important
to many users.
That's not so clear to me. It ought to be possible to really fix the problem,
i.e. accept mixed rules without the bugs in the original (unintended) feature.
Of course, this is more work than just suppressing a (well justified) error
message. If you or someone does this properly, I suppose Paul wouldn't
object.
> > I've long accepted that Debian isn't useful to me out of the box...
>
> I don't think this point was specific to Debian; rather, it was intended as
an illustration of the fact that 3+ years after 3.82 was released it still
hasn't gained widespread acceptance. Many environments are sticking with 3.81
and I suspect this is one of the factors.
I thought other distributions had long moved past the affected versions of
Linux and all the other unnamed "numerous" affected software. (Mind you, I
sometimes like Debian's conservative release schedule, but it's pretty
unique.)
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?33034>
_______________________________________________
Nachricht gesendet von/durch Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
