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").
Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-
watcher' does not exist: No such file or directory
/etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error
parsing Exec= line: No such file or directory
sn-watcher.
shipped by
time
<
it
is
wrote
I reported to both bug reports because there is something specific to
my issue.
In my case the desktop file is not only marked as obsolete in the
database. It is also still marked as owned by the old package libxapp1
... weird:
$ dpkg -L libxapp1
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libxapp.so.2.6.1
/usr/share
/usr/share/doc
/usr/share/doc/libxapp1
/usr/share/doc/libxapp1/changelog.Debian.gz
/usr/share/doc/libxapp1/changelog.gz
/usr/share/doc/libxapp1/copyright
/usr/lib/x86_64-linux-gnu/libxapp.so.1
/etc/xdg/autostart/xapp-sn-watcher.desktop
$ apt policy libxapp1
libxapp1:
Installé : 2.6.1-1
Candidat : 2.6.1-1
Table de version :
*** 2.6.1-1 500
90 http://ftp.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian trixie/main amd64 Packages
100 /var/lib/dpkg/status
2.4.2-3 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
1.2.2-1 500
500 http://httpredir.debian.org/debian buster/main amd64 Packages
ls /etc/xdg/autostart/xapp-sn-watcher.desktop
/etc/xdg/autostart/xapp-sn-watcher.desktop
dpkg -S /etc/xdg/autostart/xapp-sn-watcher.desktop
libxapp1:amd64: /etc/xdg/autostart/xapp-sn-watcher.desktop
dpkg-query -W -f='${Conffiles}\n' | grep obsolete$ |grep xapp-sn
/etc/xdg/autostart/xapp-sn-watcher.desktop a9fa3be7aaf46761adcdb856c63c125f obsolete
It could still be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389
still all the report I found in it, tell the files are owned by the new
package but still marked as obsolete.
Here, the file is still owned by the old package. I do not even have
the new package xapp-sn-watcher installed.
So maybe it is the same bug but without installing the new package the
ownership is also not removed from the old package.
This might help define the origin of this bug.
Cheers,
Alban
Il 03/10/2023 21:21, Alban Browaeys ha scritto: this is for xapp-sn-watcher not installed in this case rm_conffile will works correctly but installing also xapp-sn-watcher will remove xapp-sn-watcher.desktop broking it after the upgrade so I couldn't do it as I wrote, I did some tests looking for a workaround but unfortunately I didn't find any and the "best" solution was to not to use rm_conffile. after this new issue (with people that don't install recommends) I thinked about increase to depends but I think is a problem have circular depends (xapp-sn-watcher depends on libxapp1) so I suppose that the best thing it would fix that old bug in dpkg, but I don't know how or someone have another idea? any advice is welcome
Hi, a small update from my side. With the usual Breaks/Replaces the conffile is really taken over (the file stays in place with the local modifications in it, and the new package inherits the recorded hash), but the old package keeps the bogus "obsolete" entry forever, which is precisely the problem reported here. I have just found something that looks like a workaround on the packaging side: the remove-on-upgrade flag of DEBIAN/conffiles (dpkg 1.20.6), set in the binary package that no longer ships the conffile, through a debian/<package>.conffiles file that dh_installdeb merges with the auto-detected conffiles. Unlike rm_conffile it does not eat the file shipped by the new package, because dpkg skips the removal when another package owns the path (src/main/unpack.c, pkg_remove_conffile_on_upgrade(): "owned by other ..., remove-on-upgrade ignored"; the guard is present in 1.20.13, 1.21.23, 1.22.22 and 1.23.11). It is important to be clear that this is a removal, not a move: in the upload that actually moves the conffile, the old package is necessarily unpacked first (that is what the Breaks is for), so a conffile modified by the user is saved as .dpkg-old and replaced by the one shipped by the new package. Deferring the flag to a later upload avoids that only for the users who went through the intermediate version. This was only a quick test with a couple of throw-away packages on sid and trixie, so please take it as a hint rather than as a recipe. I will look into it more carefully the next time I actually have to move a conffile, which happens rarely enough that it may not be soon. A fix in dpkg itself, dropping the entry when another package takes the conffile over, would still be a much better outcome.