On Mon, Mar 22, 2021 at 03:19:06PM -0500, Glenn Washburn wrote: > On Mon, 22 Mar 2021 16:16:26 +0000 > Colin Watson <cjwat...@debian.org> wrote: > > On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote: > > > NAK for this patch and others "fixing" small MBR gaps. I am not > > > going to deal with this kind of issues any longer because a few > > > folks in the world cannot/do not want/... reinstall their systems. > > > Sorry guys. > > > > I'd just like to say that I think this is an unfortunate mistake, and > > puts distributions in an invidious position. > > Forgive my ignorance, this seems like a fairly simple patch. While I > personally do not like maintaining patches just solely for myself, my > understanding is that distros are quite accustomed to carrying patches > for very long periods of time (indefinitely?). Is part of the push back > because its onerous for distro/package maintainers? Or is this more a > coming from a matter of principal?
We certainly can and do carry our own patches, but it's pretty unsatisfying when the reasons for rejecting them upstream don't actually make sense (as for "buffer: Sync up out-of-range error message" and "kern/dl: Disable grub_dl_unload_unneeded"). In the last couple of rounds of security megapatches we've also seen that the amount of divergence between upstream and various distributions in security-critical code is in fact a serious problem that needs to be addressed, and so I'm not happy about adding more to it for things that touch e.g. the verifiers framework - obviously a security-critical component. However, we probably won't have any choice. Bugs of the form "I couldn't upgrade without reinstalling my entire system" are quite likely to be considered critical by any distribution worth its salt, regardless of whether upstream cares about them, and so this is likely to be just another way in which in practice distributions end up diverging from upstream. I think that's worth at least a bit of pushback. -- Colin Watson (he/him) [cjwat...@debian.org] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
