Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On 2023-02-16 11:44:25 -0700, Sam Hartman wrote:
> >>>>> "Adrian" == Adrian Bunk <bunk@debian.org> writes:
>
> Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
> >> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
> >> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
> >> > > ... > > Reasons: > > ... > > - - the change makes it
> >> impossible to create filesystems with this version of > >
> >> e2fsprogs and then run a grub-install from a target system that
> >> does not cope > > with that feature; basically breaking the
> >> debootstrap method of installing > > Debian or Ubuntu onto a
> >> server (violating #4 of the Debian social contract) > > ... > >
> >> Instead, turning on this feature should be postponed for the next
> >> release cycle > > where a proper transition can be done. > > ...
> >> >
> >> > Daniel, you are contradicting yourself when claiming that a
> >> change that > would allegedly violate the Debian social contract
> >> could be done in the > next release cycle.
> >>
> >> Actually, I'm not. ...
>
> Adrian> If not being able to install bullseye from bookworm is a
> Adrian> violation of the Debian social contract, then the same
> Adrian> rationale applies to not being able to install bullseye from
> Adrian> trixie being a violation of the Debian social contract.
>
> I don't think that arguing about whether this is a social contract
> violation makes a lot of sense.
> It seems fairly clear there is not a consensus about that.
>
> But if we're going to do that, I suggest that Adrian is putting words
> into Daniel's mouth a bit.
> Daniel has said he believes this situation violates the Social Contract
> #4, but has not explained why.
> Adrian has taken one interpretation.
> I'll propose another: "This violates the social contract because we are
> not prioritizing our users. Prioritizing users requires that we give
> them notice of incompatible changes."
> I personally think that prioritizing users requires no such thing, and
> that this change is not a violation of the SC.
> But you don't need to take the straw man position Adrian is assuming
> Daniel implies to believe this is a SC violation.
>
> But seriously, let's give up the whole is this an SC violation part of
> the discussion and move on with constructive aspects:
>
> * The RT has asked to understand the impact of the change.
>
> * Several people have proposed better documentation because it's clear
> that user (and image builder) expectations are not aligned with
> filesystem maintainer expectations.
>
> * Anyone could prepare patches to image building software to use mkfs
> options that will work with bullseye. You could also try to prepare
> patches to run mkfs out of a chroot or container of the guest OS for
> the image. I appreciate Russ strongly favors this solution, but as
> someone who has dug into image building tools a fair bit over the
> years, I think there are significant complexity and performance
> downsides to that approach. I also think that changing the mkfs
> options is more likely to get an unblock than changing the structure
> of how the tool works.
>
>
>
> * People could try to judge consensus on debian-devel or debian-policy
> about whether we want a stability guarantee ?+/- 1 release on issues
> like this. My suspicion is that you will not find a consensus, and
> that if the RT decides they don't want this change in bookworm, Ted
> will change the defaults, and if the RT is unwilling to block, we're
> left with documentation.
>
> I think all the above is more productive than arguing about whether this
> is or is not an SC violation.
Thanks for this mail. The discussion on SC#4 is not helping us to reach
a decission on this issue.
Cheers
--
Sebastian Ramacher
Reply to: