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

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

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.

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

Reply to: