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

Simon Josefsson <[email protected]> Wed, 27 May 2026 22:34:55 +0200

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

Helmut Grohne <[email protected]> writes:

> Hi Simon,
>
> On Mon, May 25, 2026 at 04:25:54PM +0200, Simon Josefsson wrote:
>> I have made the above kind of mistake embarassingly often lately.  A
>> cross-package file conflict seems like a simple problem that our QA
>> tooling should have cought for me earlier than waiting for reports.
>
> Yes, that thinking is quite popular, but what looks simple turns out to
> not be. At least in my experience.

Thanks for explaining!  Indeed, I thought this was a simpler problem.

> 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.

If we could reduce it to say 1.5GB I think it would be acceptable to put
in a container image, invoked by Salsa CI/CD.

> From my pov, the best way forward is testing migration blocking. We
> partially get that due to me filing properly versioned RC bugs now.

That assumes you file it within the 2-5 days window... which doesn't
seem like a pleasant daily routine.

> To get it fully automated, there are two prerequisites from my pov: *
> We must fix tooling issues and issues that affect many packages. For
> instance binNMUs systematically violate M-A:same.  * gcc versions
> before gcc-14 are utterly broken.  * llvm versions before
> llvm-toolchain-21 are utterly broken.  * The false positive rate must
> be reduced to an acceptable level.
>
> Are you actually interested in contributing to his or merely interested
> in $someone doing the work?

I'm not familiar with the code behind testing migration blocking. I am
familiar with GitLab CI/CD syntax, and could help with that.

For a Salsa QA job, it doesn't have to solve all corner cases.  It would
be acceptable for it to fail to detect some situations, if it catches
some trivial common situations.  Maybe such a simpler logic could be
designed, to be run after the Salsa build job.  Strawman:

Download all Content-* files (maybe pre-stored in a container image)
For all newly built X.deb do
  For all filenames F in X.deb do
    PKGS=$(grep F Content-* | grep -v X)
    for P in PKGS do
      apt-get install P X > LOG 2>&1
      if LOG has file F conflict error messsage exit 1
exit 0      

Thoughts?

This wouldn't catch symlinks/directory/permission conflicts, but I think
it would have caught the ~5 bugs that I've introduced lately.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)