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

Re: Automatisation emdebian packages



On Thu, 11 Jun 2009 23:30:09 +0200
"W. Martin Borgert" <debacle@debian.org> wrote:

> On 2009-06-11 20:59, Neil Williams wrote:
> > The vast
> > majority of Debian packages do not cross-build.
> 
> Btw. is there a howto document or wiki page, on which is
> explained to the common DD on how to verify that their packages
> are cross-buildable?

That is part of the problem. Verifying a cross-build is relatively
straightforward, in theory: 'dpkg-buildpackage -a $arch' but there is a
host of things to do before that could ever work, and that's where the
problems start.

It can be hard just getting the toolchain installed, especially when
gcc is mid-transition from the stable (4.3) to the next-default (4.4),
as it is currently. If toolchains were "official" Debian packages, that
would change dramatically.

Packages in Essential and other low-level stuff have one set of problems
- sometimes old libtool setups (needing specialised cross-building
support) or language bindings that just don't cross-build (python). Leaf
packages have a completely different set of problems - the build can be
a lot easier but getting all the cross-dependencies installed is (or
can be) hard, especially for those who are unfamiliar with
cross-building. It tends to double all the -dev and lib packages you
have installed with packages that aptitude describes as 'local or
obsolete'. Not every DD would be happy with that - so you wonder about
chroots, well, yes, but that can be a hassle all of itself with
packages that have long and/or complicated builds.

Upstream packages that *do* cross-build can be hampered by the Debian
packaging - sometimes these bugs are quite easy to fix if the
maintainer reads documents like the autotools-dev README.Debian. Other
times, especially with complex packages like gcc, ncurses or even
avahi, the Debian build system is already doing so many different
things, trying to weave cross-build support into it is very difficult
- and keeps on breaking with new versions.

Emdebian provides various tools to try and help with these situations
but even with these tools, it is still a lot of work and things
still break quite often, sadly.

The Emdebian Code Audit shows some of the current status:
http://wiki.debian.org/EmdebianCodeAudit

The QuickStart guide shows how to get some of the initial steps done:
http://wiki.debian.org/EmdebianQuickStart

Another issue is that not all DD's need to care about cross-building of
their own packages. Unless you are maintaining a package in Priority:
required, standard or Essential: yes, then cross-building might not be
that useful. e.g. there's no point trying to cross-build OOo or the
entirety of GNOME or KDE. (Bits of GNOME or KDE, yes, especially the
libraries.) Equally, if the package uses an interpreter and the
interpreter doesn't cross-build (or the relevant language bindings do
not cross-build), there is little point in testing the package (perl,
python ...).

Some maintainers refuse to apply patches for cross-build support and
refuse NMU's that would implement such support.

Finally, there are the issues to do with changing the functionality of
the build itself - cross-building isn't necessarily about just
reproducing exactly the same package as Debian, you can use Grip for
that. Cross-building is primarily to support *changing* the
functionality of the package by adding --disable-foo options to
configure, dropping dependencies, changing the package behaviour. All
of those things complicate the process of testing whether a package
cross-builds because many packages - especially those with quiet
upstreams - end up with lots of --disable- --enable- options that are
never tested in all possible permutations and then Debian adds patches
that *expect* a particular mode or configuration (generally
enable-everything) and which then fail to apply if the build config is
modified.

The tools and infrastructure to support these modifications
are just not ready, yet the reason why these tools are not ready is
that there isn't time to develop them because packages do not
cross-build cleanly . . . .

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgplw4DFDsnUV.pgp
Description: PGP signature


Reply to: