Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2

[Felix Zielcke]

Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> On Thu, Jun 11, 2009 at 01:57:36PM +0200, Felix Zielcke wrote:
> > Am Mittwoch, den 10.06.2009, 15:39 +0100 schrieb Colin Watson:
> > > On Fri, Mar 14, 2008 at 12:24:19PM +0100, Frans Pop wrote:
> > > > Currently no user parameters (such as kernel parameters, vga=, quiet) are 
> > > > included in the generated configuration file for grub2.
> > > > 
> > > > This is a blocker for making grub2 default.
> > > 
> > > The obvious way to do this seems to be to have grub-installer put the
> > > output of user-params in GRUB_CMDLINE_LINUX or
> > > GRUB_CMDLINE_LINUX_DEFAULT (as appropriate) in /etc/default/grub.
> > > 
> > > That file is currently a dpkg-managed conffile, though. Do people feel
> > > that this constitutes an intentional sysadmin change to the point where
> > > having the installer automatically modify a conffile is acceptable? (I
> > > think it's borderline; if it would be very inconvenient to make it not
> > > be a dpkg-managed conffile I think it would be acceptable.)
> > 
> > Well policy says that conffiles and maintaing the config scripts via the
> > maintainer scripts must not be mixed.
> 
> Oh, it certainly does, and for good reasons (I'm a policy editor so I'm
> familiar with it ;-) ). However, it's not clear to me whether that
> applies to changes you've requested via installer options; is that
> essentially equivalent to a manual edit? Policy is silent on that aspect
> of the subject and as I said I think it's a borderline question.
> 
> (grub-installer is, of course, not a maintainer script - "maintainer
> script" is a technical term in policy that refers to the preinst,
> postinst, etc. scripts shipped in packages' control areas - although
> perhaps that is merely a distinction of wordplay.)
> 
> > Though it says also `dpkg will ask about overwriting the file every time
> > the package is upgraded.', which maybe just means it must not be used on
> > the same file. That should be made more clear in policy.
> 
> I don't know what "it must not be used on the same file" means here.
> Could you clarify?

Sorry I meant that it isn't clear to me if policy means that mixing of
conffile with maintainer script handling of configuration is just
forbidden for the same configuartion file or if it's forbidden to mix it
always in the same package but with different configuration files
For example having /etc/grub.d/* files still as dpkg conffile
and /etc/default/grub as a maintainer script based one.

> > I already asked once #debian-devel if policy forbids editing of
> > configuration files in maintainer scripts and they said it does.
> > But even now I fail to find where it says that.
> > 10.7.3 only says that on package upgrades local changes must be
> > preserved.
> 
> 10.7.3, immediately after the bit you just quoted:
> 
>   The easy way to achieve this behavior is to make the configuration
>   file a conffile. This is appropriate only if it is possible to
>   distribute a default version that will work for most installations,
>   although some system administrators may choose to modify it. This
>   implies that the default version will be part of the package
>   distribution, and must not be modified by the maintainer scripts
>   during installation (or at any other time).
> 
> Please be aware of the technical distinction between "conffile" and
> "configuration file"; this discussion will get very confusing if you
> blur those concepts. Policy 10.7.1 describes the distinction. Conffiles
> may not be edited by maintainer scripts, but configuration files which
> are not conffiles may be edited by maintainer scripts if due care is
> taken.
> 
> The core reason for this prohibition is to ensure that users are not
> presented with spurious prompts about resolving conffile differences
> while having no idea where those differences came from; the package
> management system will tell them that they made a local change when they
> didn't. This causes confusion and must be avoided.

Ah, but /etc/kernel-img.conf is AFAICS not a dpkg conffile.
dpkg -S /etc/kernel-img.conf doestn't show any package where it belongs
to, whereas dpkg -S /etc/default/grub clearly shows grub-pc.
Anyway we solved that problem with kernel-img.conf by aborting in
preinst if it still contains /sbin/update-grub in the hooks.

> The question is whether having gone and manually typed in some extra
> boot options at the end of the installer's boot: prompt can be
> considered as equivalent to editing a configuration file; that is, can
> we expect the user to be confused when they see dpkg's conffile prompt
> or not?
> 
> I think I would be prepared to defend the claim that it doesn't really
> make a difference whether they typed those boot options at the boot:
> prompt or in an editor. Either way, they typed them manually, explicitly
> asking for their system to behave in a different way, and so a later
> conffile prompt should not be overly surprising (leaving aside the
> question of whether some people will forget they made the change, which
> is always going to be a problem no matter what we do).
> 
> If you, and others on this list, agree with that claim, then we can
> simply go ahead and have grub-installer edit /etc/default/grub to insert
> the output of user-params, on the condition that the default text - i.e.
> what you get if you just press enter at the boot: prompt - is
> character-for-character the same as what's in the conffile shipped in
> the grub-pc package. However, if you disagree, then I think it will be
> necessary to convert grub-pc (and I suppose the other grub-* binary
> packages) to manage /etc/default/grub using ucf.
> 
> > /etc/default/grub isn't that important to update on upgrades.
> > Then users would just not easily see if we introduce new variables
> > there.
> > But the files in /etc/grub.d really should be upgraded.
> > Would it maybe help if we'd switch to use ucf for them?
> 
> I think you're missing my point. I'm not proposing that any change
> should be made to the files in /etc/grub.d/; they are just fine the way
> they are, being conffiles. /etc/default/grub is the only case in
> question. Would you rather leave it as a conffile and accept the
> arguable policy violation of the installer modifying it (bearing in mind
> all the things I said above), or move it to be a ucf-managed
> configuration file? The latter is somewhat more work from you, so I
> don't want to take it for granted.
> 

Well if policy allows this which is (was?) as you can see above not
clear to me that this is allowed, then we could do this.
If I understood it correctly we'd just need to move
the /etc/default/grub to /usr/share/grub/ in the .deb and then call ucf
in the postinst to actually generate/update the /etc/default/grub one.
That wouldn't be much work but I'll ask Robert if it's okay with him.

-- 
Felix Zielcke