dpkg-cross does not do sensible things with multi-arch: same packages

[Steve Langasek]

Binary package hint: dpkg-cross

Running dpkg-cross against the Multi-Arch: same version of libc6 currently in natty does not produce sensible output. Instead it generates a .deb that contains only a large number of iconv .so modules under /usr/x86_64-linux-gnu/include, e.g.:

 ./usr/x86_64-linux-gnu/include/gconv/libCNS.so

I have no idea why it's installing to include. The source location was ./usr/lib/x86_64-linux-gnu/gconv/.

It might seem that it's not a big deal for dpkg-cross to not handle multiarch packages since multiarch packages can just be installed directly; but since we can't use foreign-architecture build dependencies on the buildds yet, cross-toolchain packages in the archive (such as armel-cross-toolchain-base) need to build using gcc-4.5-source, eglibc-source, etc. and run dpkg-cross afterwards to output their binary packages. So the armel cross-compiler in the archive isn't buildable until this is resolved.

I've checked with dpkg-cross 2.6.2 from Debian unstable; the same problem is present there.

[Wookey (wookey)]

+++ Steve Langasek [2011-03-21 05:06 -0000]:
> Public bug reported:
>
> Binary package hint: dpkg-cross
>
> Running dpkg-cross against the Multi-Arch: same version of libc6
> currently in natty does not produce sensible output. Instead it
> generates a .deb that contains only a large number of iconv .so modules
> under /usr/x86_64-linux-gnu/include, e.g.:
>
> ./usr/x86_64-linux-gnu/include/gconv/libCNS.so
>
> I have no idea why it's installing to include. The source location was
> ./usr/lib/x86_64-linux-gnu/gconv/.

You're quite right - it does indeed do that.

> It might seem that it's not a big deal for dpkg-cross to not handle
> multiarch packages since multiarch packages can just be installed
> directly; but since we can't use foreign-architecture build dependencies
> on the buildds yet, cross-toolchain packages in the archive (such as
> armel-cross-toolchain-base) need to build using gcc-4.5-source, eglibc-
> source, etc. and run dpkg-cross afterwards to output their binary
> packages.

<fx: looks at armel-cross-toolchain-base code>

Hmm. I see.

In general the right thing for dpkg-cross to do with multiarch
packages is nothing, at least in terms of moving files about. What you
want here is the ability to leave the files just where they are but
still have the 'make a package for a different arch' functionality?

Or do you in fact want the functionality of moving files into the
'old' locations even if they start in the multiarch ones (because
something about the build process needs it)? That seems very horrid

> I've checked with dpkg-cross 2.6.2 from Debian unstable; the same
> problem is present there.

The multiarch behaviour of what's in cvs (2.6.3) is different from 2.6.2. It
essentially tries to do nothing.

$ dpkg-cross -b -a amd64 libc6_2.13-0ubuntu8_amd64.deb
dpkg-cross: Skipping the 'libc6_2.13-0ubuntu8_amd64.deb' Multi-Arch package.

So that's better than the previous messing it up, and is a prefectly
reasonable way of fixing this bug. (i.e now it does something
sensible). But that doesn't help armel-cross-toolchain-base.

> So the armel cross-compiler in the archive isn't buildable
> until this is resolved.

I think we can all agree that the _correct_ fix for this is to allow
cross-arch dependencies and have the cross-toolchains built in a less-gross
way, but as we're not going to be there for a bit it seems like
allowing dpkg-cross --convert-anyway to make
libc6_2.13-0ubuntu8_amd64.deb into
libc6-amd64-cross_2.13-0ubuntu8_all.deb
might be a reasonable things to do.

--convert-anyway is currently used for 'convert when the package would
otherwise be null'. Extending it to cover 'convert even when it
multiarch and normally we'd do nothing' doesn't seem unreasonable. Can
anyone think of a reason why a different option (--force-cross?) should
be used?

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

[Steve Langasek (vorlon)]

On Tue, Mar 22, 2011 at 01:54:32AM -0000, Wookey wrote:
> In general the right thing for dpkg-cross to do with multiarch
> packages is nothing, at least in terms of moving files about. What you
> want here is the ability to leave the files just where they are but
> still have the 'make a package for a different arch' functionality?

> Or do you in fact want the functionality of moving files into the
> 'old' locations even if they start in the multiarch ones (because
> something about the build process needs it)? That seems very horrid

We do actually need dpkg-cross, when called on these packages, to "cross"
them - copying the contents to the /usr/armel-linux-gnueabi/ heirarchy -
because these resulting Arch: all crossed packages need to be installed on a
system, and such packages are *not* allowed to install contents to
/usr/lib/armel-linux-gnueabi, which policy reserves for packages of
Architecture: armel.

> > I've checked with dpkg-cross 2.6.2 from Debian unstable; the same
> > problem is present there.

> The multiarch behaviour of what's in cvs (2.6.3) is different from 2.6.2. It
> essentially tries to do nothing.

> $ dpkg-cross -b -a amd64 libc6_2.13-0ubuntu8_amd64.deb
> dpkg-cross: Skipping the 'libc6_2.13-0ubuntu8_amd64.deb' Multi-Arch package.

> So that's better than the previous messing it up, and is a prefectly
> reasonable way of fixing this bug. (i.e now it does something
> sensible). But that doesn't help armel-cross-toolchain-base.

I think this is probably good default behavior for dpkg-cross when faced
with a multi-arch package, but yes, we definitely need an override.

> > So the armel cross-compiler in the archive isn't buildable
> > until this is resolved.

> I think we can all agree that the _correct_ fix for this is to allow
> cross-arch dependencies and have the cross-toolchains built in a less-gross
> way, but as we're not going to be there for a bit it seems like
> allowing dpkg-cross --convert-anyway to make
> libc6_2.13-0ubuntu8_amd64.deb into
> libc6-amd64-cross_2.13-0ubuntu8_all.deb
> might be a reasonable things to do.

> --convert-anyway is currently used for 'convert when the package would
> otherwise be null'. Extending it to cover 'convert even when it
> multiarch and normally we'd do nothing' doesn't seem unreasonable. Can
> anyone think of a reason why a different option (--force-cross?) should
> be used?

I can't think of a reason for a separate option offhand.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Marcin Juszkiewicz (hrw)]

Hi

Ubuntu 'natty' switched to multiarch recently and my cross toolchain
packages started to fail to build. Most of problems were fixed but then
dpkg-cross hit us.

Today I looked at dpkg-cross and made attached patch to handle problem.
What patch does is converting multiarch packages into old style ones.
There is no extra switch like "--force-even-when-multiarch" and
"--convert-anyway -A" is used instead. This is change against latest CVS
code (dpkg-cross r1.83).

From my tests it looks like it does proper job.

[Neil Williams (codehelp)]

On Wed, 23 Mar 2011 15:37:34 +0100
Marcin Juszkiewicz <email address hidden> wrote:

> Ubuntu 'natty' switched to multiarch recently and my cross toolchain
> packages started to fail to build. Most of problems were fixed but then
> dpkg-cross hit us.
>
> Today I looked at dpkg-cross and made attached patch to handle problem.
> What patch does is converting multiarch packages into old style ones.

Are you sure you want to convert Multi-Arch paths to the old paths? The
idea is to get the packages concerned to use Multi-Arch paths which the
toolchain should just find without needing dpkg-cross at all. The
toolchain should be looking in the Multi-Arch paths first, then the old
cross paths.

The expected role for dpkg-cross once Multi-Arch started to be deployed
was only in putting non-Multi-Arch packages into old paths, letting the
toolchain find the other packages in their normal Multi-Arch paths.

> There is no extra switch like "--force-even-when-multiarch" and
> "--convert-anyway -A" is used instead. This is change against latest CVS
> code (dpkg-cross r1.83).
>
> >From my tests it looks like it does proper job.

It sounds like the wrong job to me. Why are the libraries IN the
correct Multi-Arch paths not being found by a Multi-Arch aware
toolchain? You need a Multi-Arch-Cross toolchain to work with
Multi-Arch and not changes to dpkg-cross. Old toolchains need to be
upgraded.

If correctly Multi-Arch'd packages are not being found by a Multi-Arch
aware toolchain, that's not something dpkg-cross should be expected to
solve.

--

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Steve Langasek (vorlon)]

Hi Neil,

On Wed, Mar 23, 2011 at 02:55:07PM -0000, Neil Williams wrote:
> On Wed, 23 Mar 2011 15:37:34 +0100
> Marcin Juszkiewicz <email address hidden> wrote:

> > Ubuntu 'natty' switched to multiarch recently and my cross toolchain
> > packages started to fail to build. Most of problems were fixed but then
> > dpkg-cross hit us.

> > Today I looked at dpkg-cross and made attached patch to handle problem.
> > What patch does is converting multiarch packages into old style ones.

> Are you sure you want to convert Multi-Arch paths to the old paths?

In a word: yes. As long as we need dpkg-cross to do anything with
Multi-Arch: same packages, the thing we need them to do is to convert them
over to the old paths.

The reason is straightforward - we need to continue crossing packages with
dpkg-cross for a time while we're transitioning to multiarch, satisfying
certain external constraints (like the fact that no buildds are configured
to install foreign-arch multiarch packages as build dependencies... or that
libc6-dev:$foreign and build-essential:$native are not currently
co-installable); and we don't want crossed packages to conflict on the
filesystem with the native multiarch packages that they're built from,
because that just makes it harder to have a smooth transition.

So since a developer might want to have both libc6-armel-cross and
libc6:armel installed at the same time during the transition, the files
still need to be moved around.

(The same thing applies to ia32-libs on x86, btw.)

> The idea is to get the packages concerned to use Multi-Arch paths which
> the toolchain should just find without needing dpkg-cross at all. The
> toolchain should be looking in the Multi-Arch paths first, then the old
> cross paths.

Yep - but we've got a lot of work to do before we're there, and we don't
want to leave the cross-compiling world broken in the meantime.

> The expected role for dpkg-cross once Multi-Arch started to be deployed
> was only in putting non-Multi-Arch packages into old paths, letting the
> toolchain find the other packages in their normal Multi-Arch paths.

This was also what I expected when viewing the matter from 10,000 feet. Now
that we're closer to the ground, I see that more involvement is still needed
from dpkg-cross during the transition.

> It sounds like the wrong job to me. Why are the libraries IN the
> correct Multi-Arch paths not being found by a Multi-Arch aware
> toolchain? You need a Multi-Arch-Cross toolchain to work with
> Multi-Arch and not changes to dpkg-cross. Old toolchains need to be
> upgraded.

> If correctly Multi-Arch'd packages are not being found by a Multi-Arch
> aware toolchain, that's not something dpkg-cross should be expected to
> solve.

It's not that the toolchain can't find the packages, it's that for
bootstrapping toolchains into the archive we need to generate an installable
libc6-armel-cross and libc6-dev-armel-cross package - and these packages
should not use the multiarch paths, because the *real multiarch packages*
want to use those. :)

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, an...

[Neil Williams (codehelp)]

On Wed, 23 Mar 2011 09:39:04 -0700
Steve Langasek <email address hidden> wrote:

> Hi Neil,
>
> On Wed, Mar 23, 2011 at 02:55:07PM -0000, Neil Williams wrote:
> > On Wed, 23 Mar 2011 15:37:34 +0100
> > Marcin Juszkiewicz <email address hidden> wrote:
>
> > > Ubuntu 'natty' switched to multiarch recently and my cross toolchain
> > > packages started to fail to build. Most of problems were fixed but then
> > > dpkg-cross hit us.
>
> > > Today I looked at dpkg-cross and made attached patch to handle problem.
> > > What patch does is converting multiarch packages into old style ones.
>
> > Are you sure you want to convert Multi-Arch paths to the old paths?
>
> In a word: yes. As long as we need dpkg-cross to do anything with
> Multi-Arch: same packages, the thing we need them to do is to convert them
> over to the old paths.

It wasn't initially clear that this was a temporary hack to get through
the transition. I'd hate to see this kind of support being used once
Multi-Arch-Cross is working and the toolchain is all done etc. As well
as removing dpkg-cross from the archive, there may need to be a package
which Conflicts: with it or certain cross-builds could Build-Conflict
with it. Yet it's the -cross packages that are the problem, if such a
problem actually exists.

There never was a good way of removing all -cross packages in one go -
I wrote emprunecross but it's reliant on detailed knowledge of the
toolchain.

We do have the dpkg-cross compatibility variable:

Provides: libgtk2.0-dev-armel-dcv1

Can't see that this would really help in this case, until we decide
that the transition is over but that would then need another upload of
the Multi-Arch package to conflict with the -dcv1 version but that
means adding one conflict for each arch.

Looks like this is just something else for each cross-building
developer to have to handle themselves. Current tools (like synaptic
and aptitude) do list all these cross packages in the "local or
obsolete" but there's other stuff in that list too.

> So since a developer might want to have both libc6-armel-cross and
> libc6:armel installed at the same time during the transition, the files
> still need to be moved around.
>
> > The expected role for dpkg-cross once Multi-Arch started to be deployed
> > was only in putting non-Multi-Arch packages into old paths, letting the
> > toolchain find the other packages in their normal Multi-Arch paths.
>
> This was also what I expected when viewing the matter from 10,000 feet. Now
> that we're closer to the ground, I see that more involvement is still needed
> from dpkg-cross during the transition.

:-) Glad to know I hadn't misunderstood the final objective....

> It's not that the toolchain can't find the packages, it's that for
> bootstrapping toolchains into the archive we need to generate an installable
> libc6-armel-cross and libc6-dev-armel-cross package - and these packages
> should not use the multiarch paths, because the *real multiarch packages*
> want to use those. :)

I'll sort this out in dpkg-cross 2.6.3 this weekend.

--

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Marcin Juszkiewicz (hrw)]

can we mark it as "fix released" now?

[Steve Langasek (vorlon)]

I think so, yes. Any further issues at this point should be filed as separate bugs.