Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Cyril Brulebois]

Theodore Ts'o <tytso at mit.edu> (2023-02-09):
> On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> > That is not going to help, because IIUC grub-install is run from the
> > target system that you are installing, and there is no
> > grub2-common-udeb.
> 
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

As Sven rightfully pointed out, there are two different environments:
 - installer, with anna and udebs (but that would be the same with apt
   and debs);
 - target.

There are no connections between both environments, so you can't have
package relationships in a cross-environment manner.

The installer uses whatever was available at build-time, or for
components that aren't built-in, whatever is available on the
installation image, or on the mirror. There's no “pulling in an overly
new version” that can be avoided. There's *one* version in the suite,
that's the one that's getting used, there's no alternative.

TL;DR: Some Conflicts, even if that were possible (which it is not)
       wouldn't achieve anything (except probably not offering any ext*
       option at the partioning step — not a huge win).

> The reason why I really don't want to add the conflicts with e2fsprogs
> 1.47 is because for people who are using sid, there is aboslutely
> nothing wrong with installing e2fsprogs 1.47.  It's only if they use
> the installer that sucks in e2fsprogs that there's a problem --- it's
> not an inherent conflict with grub per se.  If it were, then we
> shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
> is painfully slow in putting out releases --- and that's not
> reasonable.

*sigh* @ the heavy finger pointing in various parts of your mail.

> Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
> remove the default use of the csum-seed feature ---- but is it worth
> it?  Hopefully the new version of grub2 will come out soon, at which
> point I would then need to revert the hacked mke2fs.conf --- and your
> dup'ing this bug should prevent the installer from picking up
> e2fsprogs 1.47 until the new version of grub gets released.

Right now what I'm most concerned with is getting grub2 fixed in
unstable, candidate for migration into testing. Until that happens,
e2fsprogs must be kept out of testing, so that the installer cannot get
a too-new e2fsprogs with a too-old grub2.

Whether we introduce a relationship between both packages making britney
wait on grub2's being ready to allow e2fsprogs to migrate alongside it,
or we keep an RC bug on e2fsprogs to keep it out of testing until grub2
gets fixed and migrated into testing… doesn't matter much to me.


I'll word it differently because I'd like to avoid more mails on this
thread: The installer pulls components for the target system from a
single distribution, there's no set of existing packages that can be
kept around (as that would be the case for existing systems using
testing or unstable), so we need packages in the distribution being
installed to be consistent.

Right now: unstable is broken; testing isn't.


[ snip stuff about grub design ]

> Holding back file system development because grub2 uptsream is super
> slow doesn't seem like a reasonable way forward, so I really don't
> want to set this precedent.

The Bookworm freeze has started, we need to be able to install stuff, so
we need a solution for the grub2/e2fsprogs situation *now*.

I really don't care about “setting a precedent”.

[ snip brainstorming ]


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20230210/298c52ba/attachment.sig>