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

"Serafeim (Serafi) Zanikolas" <[email protected]> Wed, 27 May 2026 23:54:16 +0200
Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>
On Wed May 27, 2026 at 9:43 AM CEST, Peter Pentchev wrote:
> 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:
>> [..]
>> >>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.

right, that wouldn't work. I was thinking of merely blocking migration to
testing.

on preventing uploads, I can imagine a `Restrictions: needs-internet,
needs-sudo, superficial` autopkgtest test for each binary package of any given
source that:

1. queries an external service for candidate conflicting packages (again,
   {package, suite, arch} tuples)
2. verifies that said packages successfully install alongside the package under
   test (one at a time)
3. runs adequate for file conflict related metadata checks (which would have to
   be implemented)

that sounds pretty brittle and slow to me, and I'm sure that it wouldn't see
wide adoption without tests being autogenerated and the test generator
eventually being in autopktest Recommends (much like autodep8). ideally, we're
looking at an autodep8-like test generator that:

1. downloads and caches the 15 GB
2. determines candidate conflicting packages (without having to rely on an
   external service) and generates tests for them (to verify co-installability
   and do metadata checks)

I'm sure that there'd be many edge cases, but as long as false negatives are
near-zero, I wouldn't worry too much about perfect coverage.

thanks,
serafi
signature.asc (application/pgp-signature, 833 B)