tags 645847 help
thanks
Michael Biebl wrote:
> Package: libwildmidi1
> Version: 0.2.3.4-2.1
> Severity: normal
>
> After doing a test-upgrade from squeeze to sid, the following conffiles
> were not cleaned up during the upgrade and marked as obsolete in the
> dpkg status file:
>
> Conffiles:
> /etc/wildmidi/wildmidi.cfg cd3ca7c045e489ae6321ecd25de8023a obsolete
>
>
> See
> http://wiki.debian.org/DpkgConffileHandling
> an man dpkg-maintscript-helper on how to handle obsolete conffiles.
Thanks for testing wildmidi for this issue. Unfortunately, I'm very much
unsure how to address it, and most of the information I can find that gives
useful suggestions indicates something like openssh-client's preinst, with
commentary that this should never have to be done after the release of etch,
because dpkg would handle it automatically (this is a use case not covered
by dpkg-maintscript-helper).
I've tested upgrades from squeeze to both wheezy and sid, and can certainly
replicate the line in /var/lib/dpkg/status (and in the output from appropriate
dpkg-query calls). I have been unable to generate any prompts from dpkg about
how to manage the conffile, whether I leave it unchanged, textually modified,
or deleted. Given this experience, and the comment about this in the dpkg
source (dpkg-1.16.3:src/processarc.c:646-655), I've become unsure whether
"obsolete" in the status file (or dpkg-query calls) is a sufficient indicator
of dpkg conffile prompts.
Switching from a versioned Replaces to an unversioned Replaces does not
seem to change the behaviour on upgrades (and leaves the "obsolete" entry).
Changing the package name for the shared library seems to work, but I suspect
that would require initiating a transition for the rdepends, which seems
more than is necessary for what appears to be a cosmetic issue.
Unfortunately, all of the different methods I tried remain inconsistent
with Policy 10.7.3: specifically that the configuration file is created in
the case where the user previously deleted it: should the maintainer scripts
for libwildmidi-config be using dpkg-query to check the status of conffiles
for libwildmidi1, and then trying to guess whether this is a migration or a
new install? If so, should the logic from openssh be adopted, or is there
a more modern example? Policy 10.7.3 is respected for textual edits of the
file, or the user doing nothing at all to the file. If there are textual
edits, the conffile is silently assigned to libwildmidi-config, with the
modified version. If there are no changes, the file becomes owned by
libwildmidi-config (I'm not sure if the contents are unchanged or replaced,
but in practice it doesn't matter). If it is a new install, the conffile
was never owned by libwildmidi1, so just behaves as expected initially.
For reference, this obsolete conffile is the result of an attempt to move
the configuration from libwildmidi1 to libwildmidi-config to allow libwildmidi1
to be multiarch-compliant (/etc/wildmidi/wildmidi.cfg is not an arch-specific
path, so keeping it in libwildmidi1 would prevent the simultaneous installation
of the shared library for more than a single architecture simultaneously.
Any suggestions or assistance would be appreciated.
--
Emmet HIKORY
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
