Re: Bug#1133247: libini-config-dev has an undeclared file conflict on /usr/include/ref_array.h

Peter Pentchev <[email protected]> Wed, 27 May 2026 10:43:52 +0300

Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>

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 (application/pgp-signature, 833 B)