On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>
> I.E. I think your question of "for how long" has a very simple answer
> based on our history: if we care about stability in this instance it's
> for +/-1 Debian release.
>
> I'm struggling trying to figure out whether we should commit to that
> stability.
I recogniuze that there are precedents that go in both directions. We
have *never* required that shared library linkages created in Debian N
work in Debian N-1. Sure, there are workarounds that you can use
(e.g., compiling with -static), but I've listed workarounds for mke2fs
as well.
In other cases, we may have gone out of our way to provide these sorts
of transitions.
> I also think it would be reasonable for the project to decide we care
> about this stability, and that we want bullseye grub to work with a
> filesystem made on sid.
Well, I agree that it's a Distribution level decision. And if the
distribution decides that we should acccomodate this particular case
case, we can certainly make a Debian-specific change to the
/etc/mke2fs.conf config file which doesn't enable metadata_csum_seed
by default.
> I understand you do not support that stability decision.
The argument I would make is that it is a case by case decision, and
not a global one where *all* all generated objects created by Debian N
have to work in Debian N-1. For example, this is most manifestly
*not* true for any shared library compiled by default that uses glibc.
And I don't personally consider vmdb2 to be important enough to be
worth this kind of solicitude when we haven't done it for shared
library lankage --- just based on the popcon statistics if nothing
else.
But, if the release team belives that a note in the release notes is
not sufficient, I can certainly change the default for Debian. The
*reason* why the default features can be configured in
/etc/mke2fs.conf is because distributions or individual users might
want to make different decisions about the defaults than the upstream
maintainer of e2fsprogs. So I'll certainly abide by the ruling of the
release team in this matter, and I guess if Daniel doesn't like the
decision they make, he can always appeal this to the Debian TC.
The appeal chain on this one seems pretty clear. As the Debian
maintainer for the e2fsprogs package; I have my opinion on how this
can be resolved. Daniel has appelaed this to release team, and if
necessary, he can appeal to the Technical Committee, and he can ever
try to organize a Debian GR if he feels so strongly about the issue.
Given that there are some *very* easy workarounds, which I have
listed, just as there are simple workarounds for creating a binary for
Bookworm that will work for Bullseye, I really do believe this is a
tempest in a teacup.
Best regards,
- Ted
