[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#646288: apt-get build-dep -a $arch: wrong tradeoff for the default?



On Sat, 22 Oct 2011 14:58:01 -0700
Steve Langasek <vorlon@debian.org> wrote:

> I've been having lots of fun playing with the 'apt-get build-dep -a $arch'
> support added to apt in version 0.8.15.3 (fixing bug #632221).  As I do so,
> however, I think we've made a wrong trade-off in terms of the default
> behavior for packages.  I've actually thought this for a while, but it's
> become enough of a hassle now that I think I need to raise it as a bug and
> agitate for getting the behavior changed. :)

IIRC the reasoning for the original default was to provide
cross-building behaviour post-Multiarch which was the most similar to
cross-building behaviour under dpkg-cross, with the fundamental change
that the cross-dependencies in Multiarch world would be understood by
apt and dpkg.

Logically, I still think this should be the long term goal. What I
think we're covering here is the interim stages whilst there is this
lack of clear direction on the behaviour of -dev packages in Multiarch
and a lack of -dev packages with appropriate changes.

If we can get packages to work with the long term goal it would make it
easier to achieve the goal without having to make the changes twice.

> apt accurately implements the behavior requested on
> <https://wiki.ubuntu.com/MultiarchCross>, which says that for a package
> 
> This is correct as far as it goes, but there are a number of complications.
> 
>  - Unlike marking a package Multi-Arch: foreign, which is just adding
>    metadata, converting a -dev package to be Multi-Arch: same is not always
>    easy.  There are no best practice guidelines yet for converting a -dev
>    package to be Multi-Arch: same when it contains a mix of
>    architecture-dependent and architecture-independent headers, so many of
>    these -dev packages are not getting converted right now.  Of 696 packages
>    that have been tagged Multi-Arch: same in unstable[1], only 74 of them
>    are -dev packages.  Since some of the affected packages are pretty low in
>    the dependency tree, this effectively stops us from reaching critical
>    mass of cross-build-friendly multiarch -dev packages.

Exactly - so in the interim period where there are no clear guidelines
yet and no critical mass, do we actually need to change the default or
just accept the *result* of these complications?

>  - Whereas cross-installability of -dev packages is a must for
>    cross-building, for the vast majority of libraries, *co*installability is
>    merely a nice to have.  There are very few libraries that you need to
>    build against both the host and build versions of as part of a single
>    package build; so while it's inconvenient to have to swap -dev packages
>    out in a build environment when switching target architectures, it's
>    tolerable... especially since it would enable uses that aren't possible
>    today.  Only the apt implementation makes M-A: same a requirement.

The result being, of course, that swapping -dev packages in and out of
the build environment is simply not going to happen (because people
will generally need to be able to make a bug fix natively, cross-build
it quickly and get back to development). Instead "swapping -dev
packages in and out of the build environment" simply translates into
"requiring cross-builds to happen in chroots" like pbuilder, schroot
etc.

I think we can specify that without needing to change the default
behaviour. Are there reasons why this wouldn't work? Effectively we
don't hot-swap build-deps, we just have two build environments.

The packages which caused trouble with this in Lenny were GTK and pango
which both build native tools which are executed during the build to
generate package metadata which is used by the cross-built binaries.
There was always a problem here about potentially getting the wrong
data because the work was done on the wrong arch and potentially in the
wrong directories (due to dpkg-cross). Those problems are fixable but
*will* require the build-dependencies of the native tools to be present
in the same build environment and at precisely the same time.
libglib2.0-dev is one of the most likely here.

>  - There are a lot more library -dev packages as build-dependencies than
>    there are non-dev packages as build-dependencies, at least for the cases
>    that are interesting for cross-compilation.  If we ignore
>    build-dependencies on python, java, ruby, perl, gir, haskell, and erlang
>    packages[3], approximately[4] 60% of all build-dependencies are on
>    library -dev packages; and of the ones that are not -dev packages, there
>    are already more Multi-Arch tags set in the archive (91) than there are
>    on the -dev packages[5]!  This implies to me that many of these packages
>    will be marked Multi-Arch: foreign anyway because the tag is needed for
>    runtime.

It was always excluding the non-dev dependencies like debhelper and
native build dependencies like cmake|automake etc. which caused all the
problems with the apt-cross|dpkg-cross partnership. As long as that is
working in a way that allows apt to automatically manage upgrades to
existing packages (of both architectures), we all win.

Upgradability of cross -dev packages is the single biggest gain I need
from Multiarch. Proper cross-architecture installation dependency
resolution and management. I don't really care if I can't have -dev
packages for armel and amd64 in the same build environment initially -
as long as that can happen eventually. What I need is for armel build
dependency packages to be automatically and easily upgradable in-situ,
using apt itself, without the need for secondary tools like apt-cross,
xapt etc.

i.e. apt-get build-dep -a $arch isn't actually that much of a gain - we
can do that without MultiArch being complete.

apt-get update -a $arch ;; apt-get dist-upgrade -a $arch is FAR more
useful because it is something which has been impossible with
dpkg-cross. It worked for small values of "worked" with apt-cross and
it just doesn't work at all nicely with xapt.

> So for the above reasons I think it would be better for apt-get build-dep to
> require the DEB_HOST_ARCH package for M-A: no build-depends.

If we accept that switching -dev packages in and out of a build
environment just makes cross-building unnecessarily painful for actual
cross architecture development (rather than cross-arch distro
preparation) then we have to mandate that until the guidelines for -dev
packages are more achievable, that cross-building in MultiArch world is
restricted to chroots. If that is accepted, then it doesn't need a
change in apt - the chroot can use DEB_BUILD_ARCH in the chroot as
easily as it can use DEB_HOST_ARCH, just without needing a change to
the default.

What have I missed?
 
> Cc:ed to multiarch-devel and debian-embedded for comments.  Since this
> proposal implies pushing more patches to packages to make them Multi-Arch:
> foreign, perhaps this should be discussed on debian-devel to get a consensus
> there?

If we mandate chroots, until critical mass is achieved, would we still
need changes?

(I must be missing something somewhere ....)

-- 


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

Attachment: pgptkwmJU1ltf.pgp
Description: PGP signature


Reply to: