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

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

Hash: SHA256

On 31/01/11 20:18, Steve Langasek wrote:
> On Mon, Jan 31, 2011 at 05:16:15PM +0000, Wookey wrote:
>> So, the questions is - which of these is the correct fix:
>> 1) make dpkg-cross copy over symlinks even when they point into
>> /usr/share
>> 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
>> /usr/share/tcltk/tcl8.5
>> 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
>> instead of /usr/lib/tcl8.5 when building
> 1+2: dpkg-cross should also copy over symlinks that point to /usr/share.

The reason not to copy is that the target of the symlink does not exist
in the -cross package and the one that exists in the native package in
/usr/share contains all the wrong paths. A dangling symlink would be
left if the -cross package is not installed. If the symlink is to be
copied over not into /usr/share but into /usr/arm-linux-gnueabi/share
then the native version of the file will still exist in /usr/share and
none of the existing tools will look into /usr/arm-linux-gnueabi/share
to find the correct version without a new wrapper. Nobody wins.

dpkg-cross cannot reliably identify which symlinks should be preserved
and how. dpkg-cross cannot copy across all symlinks which point to
/usr/share because a lot of those are unwanted.

The correct fix is 2.

The only possible thing dpkg-cross could do is reverse the symlink and
move the file from /usr/share into /usr/arm-linux-gnueabi/lib/ if a
symlink to /usr/lib/ exists and not create the symlink in
/usr/arm-linux-gnueabi/share at all - at which point the native version
of the package still contains the symlink from /usr/share to /usr/lib/
with the native paths. Is that what is actually being requested for 1.?
I don't see that it's reliable - it's masking the real bug with a
horrible hack, again. How does this help when the package itself is
buggy by not complying with the FHS and the cross-build looks in the
wrong place?

> When such symlinks exist, it's almost invariably because *something is
> looking for the information in that location*.

When is this not actually a bug in that package?

The maintainer has agreed to fix the actual bug by implementing option 2
above, which we all seem to agree is the appropriate and optimal fix for
the original issue. Under what circumstances would some other package
fall into this problem *without* also being buggy in exactly the same
way as tcl8.5?

Yes, let's clarify policy but I don't think it's correct to expect
dpkg-cross to handle packages which are simply buggy whilst risking
breaking other packages which do things properly. dpkg-cross doesn't
(and shouldn't) support package-specific exceptions in how -cross
packages are created.

>  So as a general policy, they
> should also be made available in a crossed package.

The /usr/share/ location *must* change in the cross package so that it
can be installed alongside the native, at which point any merit of
retaining /usr/share is lost in the cross package because a wrapper
script will still be needed to find the modified location, handle the
dangling symlink or risk getting the wrong data (because the data in
this case is clearly wrong for the cross build).

Either the file is in the wrong place (as in this case) or the change of
location is simply going to break without a package-specific wrapper
script anyway because the locations of things in /usr/share should not
(need to) change to support a cross-build.

- -- 

Neil Williams

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: