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

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

On Thu, 3 Feb 2011 15:39:49 +0000
Wookey <wookey@wookware.org> wrote:

> dpkg-cross in fact only picks files out of packages by positive
> identification as libraries or headers. It misses out generic 'other
> stuff' in ((/usr)/lib, which generally works pretty well, but in
> this tcl case it's not suffient for tcl-depending apps to cross-build.
> Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599206 discusses
> this issue.

... and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611736 is
probably going to be the root bug (renamed) to handle the clarification
of exactly what files we keep and how we rationalise the legacy regular
expressions in dpkg-cross.

Please add further specific cases to that bug.

> dpkg-cross is intended to put files needed for cross-building into
> -cross packages and it's currently missing this one out. Unfortunately
> because it doesn't match any of the 'standard paterns for cross-useful
> files' this can only be fixed by adding a fairly specific regexp,
> which is worrying close to special-casing or deciding that in fact
> just fishing out specific things from /usr/lib is too conservative and we
> should take the view that everything in /usr/lib is potentially useful
> in cross-building and should be copied into -cross packages. 

Generally, from a cursory view of what is left out, the situation we
have is this:

0: dpkg-cross supports autotools cross-building through a series of
very detailed, very complex and potentially fragile regular expressions
but, importantly, ALSO uses a series of very detailed, very complex and
potentially equally fragile regular expressions on the CONTENTS of
those files, some of which Debian is quietly trying to drop from
packages because of other problems. (e.g .la files)

1: dpkg-cross has explicit support for pkg-config which appears to work
perfectly well, principally because pkg-config is inherently less
complex than the entirety of autoconf|automake|libtool|dpkg-shlibdeps

2: dpkg-cross has support for CMake - although only as a direct result
of 0: and 1:

3: dpkg-cross has no idea how to help SCons or any number of other
build systems out there, but then it mostly doesn't have to because
many of those simply don't compile stuff, (they create Arch:all
packages) and the ones that do compile stuff aren't used by sufficient
numbers of cross-building people for sufficient complaints to be seen
for dpkg-cross to have had the support created.

4: Nobody gave a damn about Tcl until sqlite added bindings.

5: Nobody adds support to dpkg-cross until someone complains loudly
enough *and* comes up with sane patches.

6: dpkg-cross has huge amounts of legacy code which someone added at
somepoint because it was important but nobody has actually had the guts
to unilaterally remove because we can't tell if the original package
has since been fixed. (s/fixed/broken in a different way/).

> In multiarch world everything in (/usr)/lib is going to end up in
> /usr/lib/<archtuple> or /lib/<archtuple>, unless packages are
> re-arranged to put them elsewhere, and we expect this to work
> fine so perhaps dpkg-cross should start doing the same thing, and thus
> discuver any problems this does potentially create. Would
> that actually do any harm? What files which are currently missed out
> of -cross packages would actually cause breakage if copied over into
> /usr/<triplet>/lib? 

Let's not break dpkg-cross fundamentally for everyone though. We can
choose to make a different dpkg-cross which is FAR simpler (because it
blindly moves files without any kind of safeguard) but as this does not
involve fixing the contents of certain files, numerous autotools
packages will break. So, if people want a broken dpkg-cross for
testing, let's have a dpkg-multi-cross which breaks their
cross-building world (using a different Provides: and conflicting with
the "standard" cross packages) and leave the existing world alone.

That version of dpkg-multi-cross would be trivial to write - unpack
the .deb, unconditionally move all files in ./usr/lib to ./usr/$triplet,
handle /usr/include and remove everything else. Repack the .deb as
-cross. Break world.
> I just tried a modified dpkg-cross on a pile of packages and whilst
> many come out the same, you do get quite a lot more files in some
> packages and some packages that were previously null now have stuff in
> them. e.g apache-modules. So there is quite a lot of bloat, but
> probably no breakage.

Retaining the changes to the contents of the files whilst simply adding
lots more *stuff* to -cross packages is the least harmful option.
However, because the contents haven't changed, it doesn't actually help
us identify the issues that would arise with Multiarch much.


Neil Williams

Attachment: pgp8wQhNAtyJ2.pgp
Description: PGP signature

Reply to: