Control: clone -1 -2 Control: reopen -2 Control: reassign -2 keyboards-rg Control: found -2 keyboards-rg/0.3+nmu2 Control: severity -2 serious
Cloning this bug to keyboards-rg which also needs a fix or at least go away from testing for this fix to migrate. Best, Chris On Fri, Aug 21, 2026 at 09:05:20AM +0200, Helmut Grohne wrote: > 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
