Hi Wookey, On Mon, Jan 31, 2011 at 05:16:15PM +0000, Wookey wrote: > Debian policy (8.2) says: > --------------- > It is recommended that supporting files and run-time support programs > that do not need to be invoked manually by users, but are nevertheless > required for the package to function, be placed (if they are binary) > in a subdirectory of /usr/lib, preferably under /usr/lib/package-name. > If the program or file is architecture independent, the recommendation > is for it to be placed in a subdirectory of /usr/share instead, > preferably under /usr/share/package-name. Following the package-name > naming convention ensures that the file names change when the shared > object version changes. > Files and support programs only useful when compiling software against > the library should be included in the development package for the > library > --------------- > A maintainer reading the above could reasonably decide that /usr/share > was the right place for this file, because the file itself (being just > shell) is arch-independent. The problem is that the contents are > arch-dependent. Policy is not at all clear on this distinction (It's > been making my head hurt all day). For multiarch, or existing > dpkg-cross cross-compiling, to work, arch-dependent needs to mean > either form _or_ content (see below for elaboration). I disagree that this would be a reasonable thing for the maintainer to do. The current policy language talks about architecture-dependence of the *file*, not of a file *format*, and there are obviously file formats that are architecture-independent but contain architecture-specific data that must therefore be part of an architecture: any package. So I think this is a clear policy violation in the existing tcl8.5-dev package; even if 8.2 doesn't prohibit the current behavior, the FHS surely does.[1] So I think your filing of bug #611650 was the correct course of action and the maintainer appears to agree. That said, I'm also happy to second patches to policy that clarify the wording and save maintainers from thinking it's ok to ship such files under /usr/share when it isn't. > 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. When such symlinks exist, it's almost invariably because *something is looking for the information in that location*. So as a general policy, they should also be made available in a crossed package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org [1] /usr/share : Architecture-independent data
Attachment:
signature.asc
Description: Digital signature