Hi Christoph, and thanks for your bugreport,
Le mercredi, 5 juin 2013 01.25:50, Christoph Anton Mitterer a écrit :
> On upgrade from 1.5, several old config files seem to not be properly
> removed, including:
>
> 1) /etc/cups/pdftops.conf and /etc/cups/acroread.conf
> You mention in the changelog that these were dropped.
> btw: The changelog misses the leading / for each of them.
That's really weird; cups.maintscripts has the following lines:
rm_conffile /etc/cups/acroread.conf 1.4.4-2~
rm_conffile /etc/cups/pdftops.conf 1.4.4-2~
That lead to these in the maintainer scripts:
dpkg-maintscript-helper rm_conffile /etc/cups/acroread.conf 1.4.4-2~ -- "$@"
dpkg-maintscript-helper rm_conffile /etc/cups/pdftops.conf 1.4.4-2~ -- "$@"
I could bump that version to 1.6.2-9~ to make sure they are cleaned in the
Jessie upgrade, according to dpkg-maintscript-helper manpage:
> If the conffile has not been shipped for several versions, and you are now
> modifying the maintainer scripts to clean up the obsolete file, prior-
> version should be based on the version of the package that you are now
> preparing, not the first version of the package that lacked the conffile.
Le mercredi, 5 juin 2013 01.25:50, Christoph Anton Mitterer a écrit :
> 2) dpkg: warning: unable to delete old directory '/etc/cups/ssl': Directory
> not empty Contains:
> lrwxrwxrwx 1 root root 36 Nov 14 2009 server.crt ->
> /etc/ssl/certs/ssl-cert-snakeoil.pem lrwxrwxrwx 1 root root 38 Nov 14
> 2009 server.key -> /etc/ssl/private/ssl-cert-snakeoil.key Which was likely
> added by cups... at least not by me ;)
That's kinda-expected, the directory (and it's contents) is now shipped by
cups-daemon instead, I think the warning is harmless (and actually a sign of
an intended action across upgrades).
> dpkg: warning: unable to delete old directory '/var/spool/cups/tmp':
> Directory not empty dpkg: warning: unable to delete old directory
> '/var/spool/cups': Directory not empty dpkg: warning: unable to delete old
> directory '/var/cache/cups': Directory not empty I'd guess these can be rm
> -rf'ed when cups was stopped before?
Same situation here, these files changed owner from cups to cups-daemon. And
rm -rf'ing under the feet of cups{,-daemon} is a bad idea I think.
Opinions ?
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
