Control: tag -1 patch # (because I'm not happy with this approach and wouldn't apply a patch # of this form)
On Sun, Mar 30, 2014 at 10:45:31PM +0200, Thibaut Paumard wrote: > - adds support for five variables in grub-mkconfig: > GRUB_APPLE_GMUX_INIT > GRUB_APPLE_GMUX_SELECT > GRUB_APPLE_GMUX_DISPLAY > GRUB_APPLE_GMUX_DDC > GRUB_APPLE_GMUX_POWER I should note up front that it would take a very great deal of persuasion to get me to apply Debian-specific patches that add additional variables, especially *five* additional variables, to grub-mkconfig. The reason for this is that upstream might well later apply a similar patch but with different names and/or semantics, and I'd then have to cope with migration. Furthermore, examination of such patches often results in ways to do the same kinds of things without the need for configuration, which is better for everyone. It would thus be better to discuss this kind of thing upstream (grub-de...@gnu.org) rather than in the Debian bug tracker. Honestly, though, while I understand your motivation for doing this, and it's fine as a local starting point for getting the system going, I think this ought to be done quite differently, and not at the configuration layer at all. This is not something people actually *want* to configure once it works; and the "outb" command is all very well for local hacks, but it's not a sensible framework for real hardware enablement, and we shouldn't be cluttering up configuration files that people may actually need to read with this kind of thing for various systems. Entrenching this in a configuration file in such a way that we'll need to keep supporting these variable names in the long term is really not a good plan at all. Instead, GRUB's video layer should automatically detect whether the system needs this sort of thing (for instance, by enumerating PCI devices, which GRUB can already do) and behave appropriately. As for the kernel command line changes, again, while it's often useful to set this kind of thing locally, it's not a long-term sensible way to do things. The correct approach is to get the kernel to do the right thing out of the box without the need for command-line arguments to tell it what to do. Putting this sort of thing in the GRUB packaging often works out to be a bad idea because it's very easy for these options to become wrong with later kernel versions, and then we're stuck maintaining a nightmare configuration forest. > - fills some default in /etc/default/grub. I have Debian-specific reasons to be reluctant to apply any further changes to this file: it results in conffile prompts for a large number of users, which I'd like to keep to an absolute minimum. I'm specifically uncomfortable with the approach your patch takes of adding non-trivial shell code there; I think it quite likely that there are tools around that try to parse and/or edit /etc/default/grub on the assumption that it only contains trivial assignments. Sorry, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
