On Mon, Mar 22, 2021 at 08:45:27PM +0000, Colin Watson wrote: > 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?
First of all, I am not going to make anybody lives more difficult just for the sake of making it more difficult. However, I want to make my life as a maintainer easier. > 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 OK, I was imprecise. Sorry about that. In general I am OK with the patches which are beneficial not only for the i386-pc (I will take closer look at above mentioned patches shortly). Though I am against introducing piles of ifdefery, especially into security critical stuff, to make GRUB i386-pc work with small MBR gaps. Or move code around and make it ugly just for the same thing. > 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 How long are you going to support such systems? 1, 5 or 10 years? This approach makes GRUB upstream as a hostage of small MBR gaps users. Anyway, I think we have to make users aware that small MBR gaps are not supported any longer. Otherwise we will be playing whack-a-mole game which we will loose sooner or later. > 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. Again, believe me, this is not my goal... Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
