Hi, [...] > In my mind, this is why Debian Backports exists. If you want the > latest bug fixes (including one whhich avoids data corruption when > doing off-line shrinks using resize2fs), and/or you are doing anything > at all exotic, my only recommendation is to use the Debian Backports > version of e2fsprogs.
Well, the big problem with that argument is that it presumes people know what's exotic? The man page doesn't say it's exotic. The program doesn't warn you that what you are doing is exotic. The only person who kinda knows what's exotic is you. But you don't do what would be necessary to make users aware of it. Plus, I don't even see how you would really know, given that there probably is no telemetry in e2fsck. Now that I had noticed by pure luck that a file had been corrupted during a recent conversion, I went back and found files that were corrupted during conversions that I did four years ago. Now, that was before you were aware of the bug, so nothing you could have done to prevent that, but it shows how long the damage caused by this bug can stay undiscovered/how difficult it is for you to have an accurate view of the impact of this bug. > Bottom line, for *this* particular bug (as opposed to the various > resize2fs shrink fixes) preparing an update to 1.43.4-2 is pretty > simple. Now, I don't know any details about this other bug, but simply bailing out in the risky case presumably shouldn't be that difficult either?! I mean, I can see why you wouldn't want to spend lots of time porting fixes to old versions that they don't readily apply on, and I wouldn't really see any value in that anyway. But preventing damage does not require porting the fix, bailing out does the job as well?! > And if I had any optimism that the Release Team would be > willing to take a very late update to Debian Stretch at the point when > it's just about become oldstable, I might even be willing to do the > upload. But it's not something where I'm feeling particularly > motivated to convince the release team that this is a change they > should be taking, and respinning the Stretch installer at this point. That reads more like you think the bug actually should be fixed, but the Release Team is likely to create tons of unnecessary work, and possibly preventing it anyway, that you don't feel like wasting your time with that? What is the problem with respinning the installer? That sounds like something that should be automated?! But also, fixing this only in the non-installer package sure would be better than nothing, if fixing the installer is a big problem. Regards, Florian
