Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
-----BEGIN PGP SIGNED MESSAGE-----
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
=============
http://www.linux.codehelp.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNR0GdAAoJEPFn5DyBQ7aC2lcP/1K8gLDnYffSZSb9lVarDh89
Rmvk1FLIHzJQ29kWYLE29ybpLCma7ms4T+PloVv7KLWMvS36jkLiCuM+a/sP8eU3
3uPkZ5rFTflXy8q2H4MhF/CQa94QExxthpDHgeQntz9j+5dKp+Nj3uNQaHjdh6XC
aY+tyMulpwaR/B0gpQXtgAKffqvKtInLQDXnNd4YWEXbRgMndm9d37GyzYdVdOsz
/udBf57SpQXuLX2M4d1cX1QmbUpwMqD3P7PeZQj7gcwX0loupm6MNFb7VQJM6gKp
d6o/AYBBg2X3addJMDVQZdNsNYfFm0F6JfTlk0pgNyFUOGPFmyNFxOT3QjufloY9
ZH+xmvgC9UL6gSv5voQUIezn2MSLGblP648RwW8RgdHslNG60v6I22VcZSQDkcw4
BE2CUn/Y1w+q1A74MGSAPV7lB2b9QRnxjec1xfyo11as27mudlDKwFtrGI6mzDGk
oZf/SYGkCQ1cOscq1aVJGkJocfA4rlwbM67zfFybz5W9j8UZSYOVX9F1oh/OpRPF
UQNaWyiOF4lf/EUf3Ct7F6Dwz9TPKhxpRgwg3kfQqTlsgjLK/a1zIf4F1h1EjP4H
f0sAhgJrYQkFUW8w1LDhK92EEDZdHW7De0cA/7tx4h/8ay+NdrcpEOMWTFDoGrcy
QC4k9mp+Xwnaq78yHWaz
=clO0
-----END PGP SIGNATURE-----
Reply to: