Hi Samuel, thanks for noticing this and reporting back.
On Thu, Aug 20, 2026 at 11:39:21PM +0200, Samuel Thibault wrote: > Helmut Grohne, le sam. 11 avril 2026 09:51:41 +0200, a ecrit: > > xkb-data has an undeclared file conflict. This may result in an unpack > > error from dpkg. > > > > The file /usr/share/X11/xkb is contained in the packages > > * keyboards-rg/0.3+nmu2 as present in trixie|forky|unstable > > * xkb-data/2.47-1 as present in forky|unstable > > ? /usr/share/X11/xkb is not a file, but a directory. keyboards-rg Yes, and this is part of the problem. > contains > > keyboards-rg: /usr/share/X11/xkb/symbols/eo_rg > keyboards-rg: /usr/share/X11/xkb/symbols/pancyr > keyboards-rg: /usr/share/X11/xkb/symbols/sk_rg > keyboards-rg: /usr/share/X11/xkb/symbols/sk_snk > > which are not in xkb-data, so I don't see why we would have a conflict. The conflict is not on the files you mentioned but on /usr/share/X11/xkb itself. If you look at the xkb-data side you notice that it is a symbolic link there. This is an aliasing problem very similar to /usr-merge. > I tried installing keyboards-rg, it does unpack fine concurrently with > xkb-data. Yes, that's correct. But how it unpacked now depends on the unpack order. If you unpack xkb-data first, those files will be relocated to /usr/share/xkeyboard-config-2. If you were to then remove xkb-data, the symlink were going away and the files would no longer be available. Worse, if you then remove keyboards-rg, it would fail remove the installed files as the redirecting symbolic link is now gone. This very much is a problem. > So adding a Conflicts is not necessary. Worse, it made keyboards-rg > uninstallable, since it depends on xkb-data, and now that xkb-data > conflicts with keyboards-rg, keyboards-rg has become uninstallable in > unstable, making xkb-data not migrating for 15 days. > > We want to remove the Conflicts from xkb-data. You make a very good case for the Conflicts declaration being the wrong solution for the problem at hand. As keyboards-rg depends on xkb-data (as you rightly observe), maybe it can instead rely on the presence of that symbolic link and move its own files to /usr/share/xkeyboard-config-2? At that point there would no longer be any conflict. Note that since this is an aliasing problem, you cannot just move the files and call it done. It's the same situation as the /usr-merge that caused the moratorium. If you were to do that, those files would readily disappear in a package upgrade. So for facilitating the upgrade, we need protective diversions for the aliased locations. keyboards-rg.preinst needs to check whether it upgrades from a pre-moved version. If that happens to be the case, it needs to install a protective diversion for each of the files below /usr/share/X11/xkb/ (the symbolic link) as a package that is not itself (can be one that never exists or it can be xkb-data if the maintainer agrees). When dpkg unpacks the moved package, the diversions will ensure that it does not unlink the moved files via aliasing. Then keyboards-rg.postinst needs to get rid of the protective diversions. This is not yet covering the error paths nor package downgrading. Consider using prior art. https://codesearch.debian.net/search?q=protective+diversion&literal=1 Things were becoming much easier if the files were to be renamed at the same time or moved to an entirely different location (such that no aliasing between the pre-upgrade and post-upgrade paths occurs). Helmut
