On Sun, Apr 11, 2021 at 7:22 AM Pete Batard <pete@xxxxxxx> wrote: > > Hello all, > > On 2021.04.11 04:47, Chris Murphy wrote: > > On Sat, Apr 10, 2021 at 7:54 PM Robert Scheck <robert@xxxxxxxxxxxxxxxxx> wrote: > >> > >> On Sat, 10 Apr 2021, Neal Gompa wrote: > >>> We do have those packaged in Fedora: https://src.fedoraproject.org/rpms/efifs > > Interesting. I had no idea Fedora had an EfiFs package. > > >>> The GRUB2 sources being used as an input is wrong, though. > > I think there's a major issue with the GRUB2 maintainership being > reluctant to release, even when they are critical issues (such as > BootHole) that do warrant an immediate release. > > This is causing a lot of issues downstream, with distros maintaining > their own (incompatible) forks with cherry picked patches, and, I > believe, ultimately makes people reluctant to try to upstream anything, > because, even if their patch makes it into the git repo, it may > literally be years before it appears into a dot release. > > I mentioned this explicitly on the list > (https://lists.gnu.org/archive/html/grub-devel/2020-10/threads.html#00073), > but it looks like most people there don't seem to be of the opinion that > this is a major showstopper or that dot releases are that consequential > (which, ironically, may very well due to the fact that most distros > prefer working on their own fork rather than upstream). > > If GRUB2 was what I would call a functional project, there should be no > reason for Fedora or other distros to maintain their own fork (outside > of perhaps a few supplementary patches, that shouldn't impact much of > anything), as, as is the case with other projects, I would expect distro > maintainers to be able to reach a compromise with the upstream project > to ensure that it can satisfy their needs in a timely manner, without > the need for a custom distro specific fork. > > All this to say that, the GRUB2 being used might be "wrong", but this is > really a direct result of the GRUB2 project being dysfunctional in terms > of producing releases in a timely manner, and I'd rather see pressure > being put on the GRUB 2 project to improve things in that respect, than > go with the idea that trying to upstream the patches a distro might need > has now become essentially pointless, and therefore that having each > distro maintain a fork, with a large deviation from mainline, is an > acceptable practice... > > >>> It should > >>> be using the ones from the rhboot fork: > >>> https://github.com/rhboot/grub2/commits/fedora-35 > >> > >> I am sorry, but honestly I do not have much interest to use the Red Hat > >> grub2 fork, because efifs is patching the grub2 sources as part of its > >> build process - and I am in doubt that the Red Hat grub2 fork won't break > >> this (or something else). > > I second that. You can't just ask a project to go with a dependency that > isn't mainline. Instead, issues that introduce delays with mainline > getting required updates in a timely manner need to be addressed upfront. > > >> And if I would open Pandora's box, I wonder if > >> the efifs upstream maintainer (Cc-ed) is still going to support me further > >> in case of issues (especially if caused by the Red Hat grub2 fork) - Pete? > > To be blunt: Not in a million years. > > Because EfiFs is really a side project for me (I happened to need a > read-only UEFI NTFS driver at the time, so I crafted one by reusing the > GRUB source, and, as because it was relatively easy to do, added a bunch > of file systems I didn't really need), I can't justify investing that > much time onto it, and I already have some trouble finding enough time > to address some of the issues (sometime major, such as > https://github.com/pbatard/efifs/issues/27) that get reported. > > As such, if someone comes to me with "I'm using EfiFs with non mainline > GRUB 2.0", the first thing I'll tell them is to come back if they can > replicate the issue with mainline. > > > Strictly from the perspective of, who will provide support, I think we > > want to go directly to the upstreams as much as possible. When GRUB's > > file system modules get updates, they appear first upstream, and it'll > > just delay things to have to wait for Fedora's GRUB to be rebased to > > get those updates. > > Another good point. > > This is indeed a two way street: Some of the updates Fedora might want > may ultimately take time to appear upstream, which make it easy to want > to use the Fedora fork as the source, but some critical updates may also > appear in mainline, long before Fedora picks them up (especially if they > create integration conflicts with Fedora's own changes which becomes > more an more of a probability as a fork deviates from mainline). > To be absolutely clear, I completely agree with everything here. However, with GRUB being completely dysfunctional upstream and all the pressure from everyone else basically doing nothing, I don't know what else we're supposed to do. Outside of Fedora, I help maintain GRUB for other distributions, and I wound up having no choice but to use the Red Hat tree to get *any* maintained improvements. If there was any light at the end of the tunnel, I would say my own suggestion is completely ridiculous. However, the *major* reason for my suggestion to use the Red Hat tree is that the Btrfs driver has the SUSE patches to be able to read and boot from subvolumes, which are not upstream. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
