After switching from rxvt-unicode-256color to rxvt-unicode (see
#848284), dpkg-query reports a conffile as obsolete:
,----
| $ dpkg-query -W -f='${Conffiles}\n' | grep obsolete$
| [...]
| /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b obsolete
| $ dpkg -S /etc/X11/app-defaults/URxvt
| rxvt-unicode: /etc/X11/app-defaults/URxvt
`----
This is bogus since the file is shipped in the package, otherwise it
would belong to rxvt-unicode-256color which was its previous owner.
Here is the relevant excerpt from the dpkg log:
,----
| $ grep rxvt-unicode /var/log/dpkg.log
| 2018-01-05 08:38:30 upgrade rxvt-unicode-256color:i386 9.22-1+b3 9.22-2
| 2018-01-05 08:38:30 status half-configured rxvt-unicode-256color:i386 9.22-1+b3
| 2018-01-05 08:38:30 status unpacked rxvt-unicode-256color:i386 9.22-1+b3
| 2018-01-05 08:38:30 status half-installed rxvt-unicode-256color:i386 9.22-1+b3
| 2018-01-05 08:38:30 status half-installed rxvt-unicode-256color:i386 9.22-1+b3
| 2018-01-05 08:38:30 status unpacked rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:38:30 status unpacked rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:38:30 install rxvt-unicode:i386 <keine> 9.22-2
| 2018-01-05 08:38:30 status half-installed rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:30 status unpacked rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:30 status unpacked rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:31 configure rxvt-unicode:i386 9.22-2 <keine>
| 2018-01-05 08:38:31 status unpacked rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:31 status unpacked rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:31 status half-configured rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:31 status installed rxvt-unicode:i386 9.22-2
| 2018-01-05 08:38:34 configure rxvt-unicode-256color:all 9.22-2 <keine>
| 2018-01-05 08:38:34 status unpacked rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:38:34 status half-configured rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:38:34 status installed rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:43:03 status installed rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:43:03 remove rxvt-unicode-256color:all 9.22-2 <keine>
| 2018-01-05 08:43:03 status half-configured rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:43:03 status half-installed rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:43:03 status config-files rxvt-unicode-256color:all 9.22-2
| 2018-01-05 08:43:03 status config-files rxvt-unicode-256color:all 9.22-2
`----
Purging the rxvt-unicode-256color package helped, although that package
did not contain any files according to "dpkg -L" (I had already removed
but not purged it). Now the conffile is no longer reported as obsolete.
Cheers,
Sven
Hi! This does not show what package owned that obsolete entry, though. But in principle that should have been rxvt-unicode-256color. Both packages will have such conffiles listed in their Conffiles fields, but the old one might have an obsolete entry, which will be ignored by dpkg for most operations. Was going to ask for the -s output for both packages, but it's too late now. :) Well, barring reinstalling the older package. Thanks, Guillem
That seems to be correct. What I find confusing is that neither
"dpkg -S /etc/X11/app-defaults/URxvt" nor
"dpkg -L rxvt-unicode-256color" give any hint about this. What is the
point of leaving the obsolete conffile in the dpkg database then?
It was easy to replicate the upgrade, so here is the output which I
think matches your expectations:
,----
| $ dpkg -s rxvt-unicode rxvt-unicode-256color
| Package: rxvt-unicode
| Status: install ok installed
| Priority: optional
| Section: x11
| Installed-Size: 3312
| Maintainer: Ryan Kavanagh <rak@debian.org>
| Architecture: i386
| Version: 9.22-2
| Replaces: aterm (<< 1.0.1dummy), aterm-ml (<< 1.0.1dummy), rxvt (<< 1:2.7.10-7.1~), rxvt-ml (<< 1:2.7.10-7.1~), rxvt-unicode-256color (<< 9.22-2), rxvt-unicode-lite (<< 9.22-2)
| Provides: aterm, rxvt, x-terminal-emulator
| Depends: libc6 (>= 2.17), libfontconfig1 (>= 2.12), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.2), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libperl5.26 (>= 5.26.0~rc1), libstartup-notification0 (>= 0.2), libx11-6, libxft2 (>> 2.1.1), libxrender1, base-passwd (>= 2.0.3.4), ncurses-term (>= 5.8-1)
| Recommends: fonts-dejavu, fonts-vlgothic | fonts-japanese-gothic
| Breaks: aterm (<< 1.0.1dummy), aterm-ml (<< 1.0.1dummy), rxvt (<< 1:2.7.10-7.1~), rxvt-ml (<< 1:2.7.10-7.1~)
| Conflicts: rxvt-unicode-256color (<< 9.22-2), rxvt-unicode-lite (<< 9.22-2)
| Conffiles:
| /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b
| Description: RXVT-like terminal emulator with Unicode and 256-color support
| rxvt-unicode is a modern, Unicode-aware color xterm replacement that uses
| significantly less memory than a conventional xterm and many other Unicode
| supporting terminal emulators.
| .
| It supports using multiple fonts at the same time, including Xft fonts, and
| client-server technology to reduce memory consumption when using multiple
| windows.
| .
| This package is configured with 256-color support, and TERM set to
| "rxvt-unicode-256color". Any other systems you log into must have this
| terminfo entry installed!
| Homepage: http://software.schmorp.de/pkg/rxvt-unicode.html
|
| Package: rxvt-unicode-256color
| Status: deinstall ok config-files
| Priority: optional
| Section: x11
| Installed-Size: 62
| Maintainer: Ryan Kavanagh <rak@debian.org>
| Architecture: all
| Source: rxvt-unicode
| Version: 9.22-2
| Config-Version: 9.22-2
| Depends: rxvt-unicode (>= 9.22-2)
| Conflicts: rxvt-unicode (<< 9.22-2)
| Conffiles:
| /etc/X11/app-defaults/URxvt 7b221a2da49507e31f42e702791b085b obsolete
| Description: dummy transitional package for rxvt-unicode
| This is a dummy transitional package transitioning rxvt-unicode-256color to
| rxvt-unicode. It can safely be removed.
| Homepage: http://software.schmorp.de/pkg/rxvt-unicode.html
`----
Cheers,
Sven
Hello,
since update of today also keyring files are marked as obsolete conffile:
% dpkg-query -W -f='${Conffiles}\n' | grep -E '(grub|archive).*obsolete$'
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg
64d549adf06d734bb947d742898d9a19 obsolete
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg
a81b62d3b02f6e9781e6639bf6fc050b obsolete
/etc/kernel/postrm.d/zz-update-grub 536d9d45e3e547638db3c5d58a925b6c obsolete
/etc/kernel/postinst.d/zz-update-grub 536d9d45e3e547638db3c5d58a925b6c obsolete
https://bugs.debian.org/912144
https://bugs.debian.org/886389
kind regards,
Thilo
TS schrieb/wrote: sorry for that my fault. Wheezy keys have been removed. https://bugs.debian.org/901320 kind regards, Thilo
Hello Guillem,
I think that I have hit the same bug when splitting the `mime-support`
package into `media-types` and `mailcap`:
mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
package containing only a changelog and a copyright file, and depends on
media-types and mailcap. And these two packages declare a Breaks and
Replaces relationship against mime-support << 3.65.
As a result of the upgrade, the conffiles are now owned by the new
packages. But dpkg still keeps a record that the mime-support has
the "obsolete" version of them:
# dpkg-query -W -f='${Conffiles}\n' media-types
/etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530 /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n' mailcap
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n' mime-support
/etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
Is there something we can do about that ?
Have a nice day,
Charles
Hi, I had the same issue when moving conffiles from one xapp package to another (of the same source), I did a test also with rm_conffile but on first upgrade remove the conffile of the new package remaining without the file (very bad thing) so I keep it marked as obsolete (which is less worse). Some days ago I had to do another conffile move in xapp (package split to solve a policy issue) e one also in freeipmi, I searched and asked on irc for a solution to avoid the "obsolete conffile issue" but not found for now :( can someone tell me if there is a way to workaround this on packaging waiting for a definitive solution please? thanks for any reply and sorry for my bad english
Hi! If you use rm_conffile then the conffile will be removed, which is definitely not what you'd want when taking over ownership from another package. Having the conffile marked as obsolete in the database should at most be untidy cruft, perhaps confusing to users, but the tools should all handle that fine (otherwise they are buggy and should be fixed). Or is there any other issue with these conffiles being marked as obsolete that has not been reported? Thanks, Guillem
Il 17/12/2021 03:49, Guillem Jover ha scritto: Thanks for reply, rm_conffile was only a test I did trying to solve/workaround this "obsolete issue" For now I saw only "marked as obsolete" and not other issue, but if users want clean "obsolete" conffiles manually I suppose it become problematic (I don't know if there is also tools that do it "automatically").