hi Helmut, On Tue May 26, 2026 at 7:30 AM CEST, Helmut Grohne wrote: > On Mon, May 25, 2026 at 04:25:54PM +0200, Simon Josefsson wrote: [..] > I started experimenting with what is available in > https://salsa.debian.org/helmutg/dacpa.
it seems like this repo is not available anymore.
> there are very many tricky corner cases that look obvious but are not.
> I'm glad that you call my reports excellent, but that's largely due to
> me double checking every single one of them.
>
> Roughly speaking what you need here is:
[..]
> So in your additional salsa job you now have a choice. You gather all
> this data for your package and send it off to a network service that has
> those 15GB. Or you download those 15GB. Neither of these sounds
> particularly attractive for a salsa job to me.
agree.
>>From my pov, the best way forward is testing migration blocking.
I'd think that the closest to this functionality is piuparts -- both in terms of
testing a package's installed state and in failures leading to bug filing
(albeit manual).
one possibility would be to have a new service that has all of the necessary
inputs (the aforementioned 15 GB) and given as input a {package, suite, arch}
returns a list of {package, suite, arch} candidates, with which each one of the
former _might_ conflict. the service could implement easy checks (e.g. Conflicts
declarations) to reduce false positives, but it need not be perfect.
piuparts, when testing a package, would (i) query the new service to get the
potentially conflicting candidates, and (ii) try installing each one at a time
alongside the package under test. that'd filter out the false positives, and
fail loudly (leading to bug filing) when the installation fails or
when file checksums/permissions/owner/group change.
thanks,
serafi
signature.asc
Description: PGP signature
