-----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:
- 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/