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

[Felix Zielcke]

Am Donnerstag, den 11.06.2009, 17:22 +0100 schrieb Colin Watson:
> On Thu, Jun 11, 2009 at 04:18:04PM +0200, Felix Zielcke wrote:
> > 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:
> > > > 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.
> 
> Policy is talking at the level of individual files. There is no problem
> with having /etc/grub.d/* as conffiles and /etc/default/grub as an
> ordinary configuration file.
> 
> > > 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.
> 
> *blink* I didn't mention /etc/kernel-img.conf, so I'm not sure where
> this is coming from? You're correct that it isn't a conffile.
> 
> > Anyway we solved that problem with kernel-img.conf by aborting in
> > preinst if it still contains /sbin/update-grub in the hooks.
> 
> I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub
> migration has been a hopelessly confusing mess. Please don't use it as
> an example of anything except how *not* to do things.
> 
> Either /sbin/update-grub should have continued to be supported forever
> as a symlink without warnings, or (preferably) something should have
> taken care of detecting the situation and rewriting the configuration
> file automatically. Robert even suggested a way to do this in #361929,
> but it was never done for some reason that is mysterious to me.
> Complaining about the situation and aborting is the worst of both
> worlds; it often merely throws users into confusion, or at best leaves
> them cursing about how Debian didn't just sort out its own mistakes
> rather than making users take care of it by hand.
> 
> I understand, of course, that there are all sorts of reasons why these
> sorts of things happen at the time; but if you look at the change as a
> whole then it was very clearly far from optimal.

I saw that bug report now for the first time.
(I just jumped in almost exactly a year ago into the grub packages).
I thought about running sed over kernel-imf.conf too but both Robert and
me were unsure if policy allowed that and #grub-devel said so.
But if even you would prefer to just automatically edit it then we'll do
so.
I looked it up in the changelog of grub-legacy. Since the release of
etch the wrapper in /sbin/update-grub which warns the user is in place.
Though it could have mentioned that you probable need to edit
kernel-img.conf
We got a pretty recent bug report in grub2 (500631) that there is at
least one user who didn't change it yet.

> > > 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
> 
> If policy allows the installer to modify /etc/default/grub, then you
> (the grub2 maintainers) don't need to do anything. That's why I asked on
> this list. :-)

Ah okay, but ucf would be given us anyway the advantage of 3-way merge.
Though /etc/default/grub probable won't change that often.

> If policy does *not* allow the installer to modify /etc/default/grub,
> then:
> 
> > 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.
> 
> ucf is quite an advanced packaging thing with plenty of potential
> complicated corners, so you should definitely check with somebody who's
> done it before. :-)

Luckly I remembered that dovecot switched to ucf.
Seems like they removed all the ucf upgrade stuff from the package but
the original bug report about it has the patch which handles it.
-- 
Felix Zielcke