Hi Chris and Matthew,
On Tue, Sep 01, 2026 at 08:35:44AM +0100, Matthew Vernon wrote:
> On 01/09/2026 08:23, Chris Hofstaedtler wrote:
>
> > On Tue, Sep 01, 2026 at 08:47:27AM +0200, Christian Klein wrote:
> > > The latest upgrade broke installation of libpcre2-dev:i386 alongside
> > > libpcre2-dev:amd64.
> > > Building wine requires the packages installed.
> > >
> > > Unpacking libpcre2-dev:amd64 (10.48-1) over (10.46-1+b2)…
> > > dpkg: error processing archive
> > > /var/cache/apt/archives/libpcre2-dev_10.48-1_amd64.deb (--unpack):
> > > trying to overwrite shared '/usr/bin/pcre2-config', which is different
> > > from
> > > other instances of package libpcre2-dev:amd64
> > > Errors were encountered while processing:
> > > /var/cache/apt/archives/libpcre2-dev_10.48-1_amd64.deb
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > >
> > > Looking at pcre2-config, it now includes the architecture triplet, thus
> > > making
> > > it no longer mutiarch installable. Older versions of the package shipped
> > > without that extra case statement.
> >
> > I've CCed Helmut for m-a advice. I think -dev packages do not
> > necessarily need to be Multi-Arch: same. Maybe libpcre2-dev does to
> > satisfy some m-a chain. If it does, then it must fulfill the
> > property (thus adjusting severity).
> > Maybe libpcre2-dev does not need to be M-A: same, then it can just
> > drop that flag from d/control.
I concur that usually -dev packages do not require M-A:same for cross
building. However, it is very convenient for developers to have them
M-A:same (which is also why you see these bug reports) as they can use a
single development environment for native and cross building.
> the merge conflict in pcre2-config.in and my previous notes on why I'd
> patched it, and incorrectly thought that the issue was that its _output_
> should not vary on our various architectures.
>
> I think the right answer is probably to patch it back to how it was in in
> 10.46 i.e. just:
>
> "
> libR=
>
> libS=
> "
>
> I plan to do this today - Helmut, would you care to confirm that's correct,
> please?
This sounds very plausible. What I see in unstable is adding
-L/usr/lib/${DEB_HOST_MULTIARCH} to libS. Dropping that code (which
seems to be the only architecture-dependent aspect) should not pose any
downsides on Debian, because that location is on the default search
path. This is the kind of patch that exists for Debian and does not have
to be upstreamed as it is not relevant to other distributions.
Helmut
