Re: Review request: debconf templates for mrtg

Eriberto Mota wrote:
> You are right again. However, this is a big effort for a minimum of
> machines (or none for now) in this situation. I decided just to show
> a message for the users.

Are you saying most MRTG users don't have any customisations in their
mrtg.cfg that they'll need to keep, or just that MRTG has a very low
popcon, or what?
 
>> Just for the exercise, I'll review the text anyway.
>> 
>>   Template: mrtg/move_config_file
>>   Type: note
>>         ^^^^
>> If the new mrtg will ignore /etc/mrtg.cfg, this should probably be
>> "Type: warning".
> 
> I understand your suggestion, but "warning" is not acceptable for "Type"
> in debconf[1].
> 
> [1] https://www.debian.org/doc/packaging-manuals/debconf_specification.html#id-1.4.4.3.1

Apparently I'm badly out of practice for these template reviews - I've
got that page bookmarked, but I was misremembering it as "note" versus
"warning" instead of "text" versus "note".
 
>>   _Description: /etc/mrtg.cfg should be moved to /etc/mrtg/mrtg.cfg
>>   Older versions of MRTG on Debian had the configuration file /etc/mrtg.cfg.
>>   This file should now be located in the directory /etc/mrtg/. The Debian
>>                                                                ^^^
>> Just "Debian Policy", no "The".
>> 
>>   Policy doesn't allow the installation system to change the place of the
>> 
>> This isn't true.  Meanwhile, we try to avoid letting debconf talk
>> about debconf, and it can be confusing to mention installation in a
>> prompt that might be shown during a routine upgrade.
>> 
>>   configuration files already present in the system (see Policy 10.7.3).
>>   Please, consider to make the needed adjustments in your system manually.
> 
> I will use "installer". I think is important to say this word.

I can't see why.  The (Debian-)Installer is a completely different
thing; and users will only see this message during a (multi-)package
(dist-)upgrade, not when they're running a fresh "apt install mrtg".

If you need to talk about the internals at all, you might say "Policy
doesn't allow a package upgrade process to do X", but I don't think
you need to mention Debian Policy here at all - it just gives the
unfortunate impression that you're complaining about having to produce
a package that isn't buggy!

>> This seems an unnecessarily gentle suggestion, and it doesn't need to
>> mention "in your system" - just say
>> 
>>   Please make the required adjustments manually.
> 
> My new approach is now:
> 
> Template: mrtg/move_config_file
> Type: note
> _Description: /etc/mrtg.cfg should be moved to /etc/mrtg/mrtg.cfg
>  Older versions of MRTG on Debian had the configuration file /etc/mrtg.cfg.
>  This file should now be located in the directory /etc/mrtg/.
>  .
>  Debian Policy doesn't allow the installer to move a file from a place to
>  another, discarding any user changes (see Policy 10.7.3). Please, make the
>  required adjustments manually.

This implies that moving files results in discarding user changes.
No, it's using direct "mv" commands in the postinst that results in
bugs.  Maybe the diplomatic way of saying "I can't be bothered to do
the whole officially approved mv_conffile song and dance routine for
this" is something like

  Older versions of MRTG on Debian had the configuration file /etc/mrtg.cfg.
  The new version reads from /etc/mrtg/mrtg.cfg instead.
  .
  Migrating local customizations to the new location is too complicated to
  automate at present, so you will need to move your configuration across
  manually.

Or maybe "so MRTG will not work correctly until you move your
configuration across manually"?

> What you think?

I'm assuming that the obvious user-visible effect of this change is
that the new version of MRTG will ignore the customisations that are
in the old location.  I'm also assuming that it's only showing this
template to users with a customised /etc/mrtg.cfg, not unconditionally
on upgrade - oh, except now I see that the default mrtg.cfg is almost
empty, and there's a special "cfgmaker" script for generating a
version that will work for your network setup.  So are users more
likely to want to do this migration with "mv" or "cfgmaker"?

(If the latter, we might perhaps warn them that "sudo COMMAND > FILE"
can only modify a FILE that your current user has write-access to...)