Hi! On Mon, 2025-05-19 at 09:58:07 +0200, John Paul Adrian Glaubitz wrote: > On Mon, 2025-05-19 at 09:49 +0200, Guillem Jover wrote: > > sqv is not available on all ports, so that would make it fail on all > > those ports then. I think a versioned build-conflicts would have been > > better (but I didn't think there would be outdated versions), but that > > would then make it uninstallable on the affected ports anyway. Using an > > arch-restricted build-dependency would be another alternative but I don't > > feel like tracking where sqv is available over time on dpkg's build > > dependencies (this seems wrong to me), and would also not fix the issue at > > hand (on the affected ports dpkg would either be uninstallable, or if not > > listed, still fail due to the binary being present but not new enough). > > So, what does it then use at the moment? How does it figure out whether sqv > is available or not. You somehow have to whitelist the architectures with > sqv, no?
dpkg has multi-backend OpenPGP support and will try to use any of the backends it supports if the commands are available: gpg/gpgv, gpg-sq/gpgv-sq, sq/sqv, or any available SOP/SOPV implementation (sqop/sqopv, rsop/rsopv, gosop, pgpainless-cli. If sqv is not available it will fallback to any other alternative, or for the particular test suite, it will just skip the tests. On Mon, 2025-05-19 at 10:03:02 +0200, Samuel Thibault wrote: > John Paul Adrian Glaubitz, le lun. 19 mai 2025 09:58:07 +0200, a ecrit: > > > If getting a new sqv version built is going to be too hard or time > > > consuming for now, then perhaps removing the sqv binary packages from > > > the port (like it's the state for several other ports) is the quickest > > > fix to be able to build dpkg, as I mentioned in my original mail. > > > > Well, this is something Aurelien has to do. I don't have any access to > > the Ports FTP servers, so I can't just easily remove packages, > > unfortunately. > > On hurd-any at least, apt currently depends on sqv, so removing sqv > would make apt uninstallable. Yes, as mentioned on my original mail, going this route might require rebuilding apt. Checking now, it seems apt will also become a problem, because if it gets built it will unconditionally generate a strict versioned dependency on «sqv (>= 1.3.0)» if the /usr/bin/sqv program is found, which would not be satisfiable on hurd-*. Checking apt now, I see «apt/debian/rules:override_dh_gencontrol», and «apt/CMakeLists.txt:.*SQV_EXECUTABLE» and «apt/methods/CMakeLists.txt:.*sqv». So I think removing the binary packages, and rebuilding both apt and dpkg would be the best course of action. Thanks, Guillem
