On Tue, May 26, 2026 at 11:32:11PM +0200, Serafeim (Serafi) Zanikolas wrote: > 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.
How would that work for a package that has not yet been uploaded into the archive yet? I think part of the reason for this thread was to figure out a way to *prevent* uploading packages with file conflicts. That means, first and foremost, making sure that any new files that the new package version installs will not conlict with others. G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
