On Mon, Feb 01, 2010 at 11:17:19PM +0000, Simon McVittie wrote:
> On Mon, 01 Feb 2010 at 20:46:18 +0100, Goswin von Brederlow wrote:
> > > Goswin wrote:
> > >> Looks fine from here. How does your -dev package look? The .so link, .la
> > >> and .pc files (if any) are specifically important.

> > > The -dev package has no Multi-Arch field, which seems to be how the multiarch
> > > spec on the Ubuntu wiki intends things to be done? As such, I'm still using
> > > /usr/lib for the -dev part.

> > Initialy yes. But esspecially for cross compiles multiarch dev packages
> > would be nice. But that will need more developement.

> In the meantime, is there consensus that shuffling the development files into
> /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
> appropriate for -dev packages where all the arch-dependent files are in
> arch-specific directories? I'd rather not break future work if -dev packages
> aren't really settled yet.

The policy exception is currently not written to permit this. Please don't
upload packages to the archive that violate policy.

(-dev is not handled because there hasn't been enough time yet for a
fleshed-out proposal with enough eyeballs on it to make sure something
hasn't been misdesigned. It /seems/ obvious that -dev packages should be
able to follow the same rules as runtime lib packages, but .pc and .la
files, for example, add new wrinkles, and we shouldn't be pushing to the
archive before we're confident we have it right.)

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

Steve Langasek wrote:
> On Mon, Feb 01, 2010 at 11:17:19PM +0000, Simon McVittie wrote:
> > In the meantime, is there consensus that shuffling the development files into
> > /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
> > appropriate for -dev packages where all the arch-dependent files are in
> > arch-specific directories? I'd rather not break future work if -dev packages
> > aren't really settled yet.
>
> The policy exception is currently not written to permit this. Please don't
> upload packages to the archive that violate policy.

I'd interpreted Policy §9.1.1 (3) as allowing anything that would normally be
installed to [/usr]/lib to be installed to [/usr]/lib/TRIPLET, but looking
at it again, it does indeed specify "object files, internal binaries, and
libraries". Am I right in thinking that this means the following?

* the real runtime library (libdbus-1.so.3.4.0) and the SONAME symlink
(libdbus-1.so.3) SHOULD move to the multiarch directory

* binaries appropriate for ${libexecdir} SHOULD move to a subdirectory of the
multiarch directory

* the development symlink (libdbus-1.so) and the static library (libdbus-1.a)
MAY move to the multiarch directory

* plugins (e.g. /usr/lib/gtk-2.0/modules) MAY move to a subdirectory of the
multiarch directory (but this will need coordination between the maintainers
of the plugin loader and the plugins)

* .la files MUST NOT move to a subdirectory of the multiarch directory;
http://wiki.debian.org/ReleaseGoals/LAFileRemoval will eventually make this
irrelevant
[rationale: earlier in the thread, Goswin explained that this doesn't work]

* architecture-specific header files currently found in /usr/lib (on my
system: D-Bus, GLib, Gtk, ejabberd) MUST NOT move to a multiarch directory
[rationale: Policy doesn't yet say they can]

* miscellaneous architecture-specific non-library data (pkg-config .pc files)
MUST NOT move to a multiarch directory
[rationale: Policy doesn't yet say they can]

In each case where I'm wrong, could you please explain whether putting those
files in multiarch directories is currently forbidden, discouraged, encouraged
or recommended?

For autotools packages that hard-code paths, usually because they have plugins
(gtk-2.0 is a good example), the only reliable way to divert the runtime
library into /usr/lib seems to be to use `./configure --libdir=TRIPLET`,
which means that files destined for any directory of the form ${libdir}/foo
will get diverted too, even if current Policy forbids this. Should maintainers
be using --libdir and then moving forbidden files (e.g. pkg-config files)
back to the arch-neutral location, or encouraging upstreams to provide
more --whateverdir switches, or what?

A concrete example: if I understand correctly, Goswin suggests I use --libdir
on dbus, to make it more exemplary, and in particular not misleading for
maintainers of packages that do hard-code paths. However, I would then need
to move the .pc file and the arch-specific header back out of the multiarch
directory to comply with what you said, editing the .pc file to have the
right path for the arch-specific header in the process, unless I patch
configure.ac to add some sort of --archincludedir option, autoreconf, and
use that option.

Regards,
Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Simon McVittie
>
> | In the meantime, is there consensus that shuffling the development files into
> | /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
> | appropriate for -dev packages where all the arch-dependent files are in
> | arch-specific directories? I'd rather not break future work if -dev packages
> | aren't really settled yet.
>
> while it probably doesn't hurt, it's not been specified yet.
> Personally, I'd rather see us get the necessary changes to support
> running multiarch binaries in place before starting to move development
> libraries.
>
> [...]
>
> | > Architecture dependent header files belong under
> | >
> | > /usr/include/triplet/
> |
> | Is there consensus that that's the right place? I don't see any mention on
> | <https://wiki.ubuntu.com/MultiarchSpec>, which is the nearest I've seen to
> | a canonical description of the current state of multiarch (no pun intended).
>
> It's the only place that has been discussed, but again, the spec is for
> running multiarchified binaries, not compiling against them. I wouldn't
> upload packages containing includes in triplet directories yet.

Support for /usr/include/triplet/ is in oldstable and stable.
And it is already being used:

% zgrep usr/include/x86_64-linux-gnu Contents-amd64.gz
usr/include/x86_64-linux-gnu/ffi.h libdevel/libffi-dev
usr/include/x86_64-linux-gnu/ffitarget.h libdevel/libffi-dev

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Simon McVittie <smcv@debian.org> writes:

> Steve Langasek wrote:
>> On Mon, Feb 01, 2010 at 11:17:19PM +0000, Simon McVittie wrote:
>> > In the meantime, is there consensus that shuffling the development files into
>> > /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
>> > appropriate for -dev packages where all the arch-dependent files are in
>> > arch-specific directories? I'd rather not break future work if -dev packages
>> > aren't really settled yet.
>>
>> The policy exception is currently not written to permit this. Please don't
>> upload packages to the archive that violate policy.
>
> I'd interpreted Policy §9.1.1 (3) as allowing anything that would normally be
> installed to [/usr]/lib to be installed to [/usr]/lib/TRIPLET, but looking
> at it again, it does indeed specify "object files, internal binaries, and
> libraries". Am I right in thinking that this means the following?

I'm just stating what is required for a package to conform to
Multi-Arch: same. In cases where you feel policy disagrees or support is
still unclear that means the package can not be Multi-Arch: same yet.

> * the real runtime library (libdbus-1.so.3.4.0) and the SONAME symlink
> (libdbus-1.so.3) SHOULD move to the multiarch directory

MUST for Multi-Arch: same.

> * binaries appropriate for ${libexecdir} SHOULD move to a subdirectory of the
> multiarch directory

MUST for Multi-Arch: same.

> * the development symlink (libdbus-1.so) and the static library (libdbus-1.a)
> MAY move to the multiarch directory

MUST for Multi-Arch: same. BUT -dev packages need not be multiarchified
yet. Do test and upload to experimental and such when playing with this.

> * plugins (e.g. /usr/lib/gtk-2.0/modules) MAY move to a subdirectory of the
> multiarch directory (but this will need coordination between the maintainers
> of the plugin loader and the plugins)

MUST for Multi-Arch: same. And gtk-2.0 is one of the important libs that
people need multiarchified. Having a multiarch libgtk but no multiarch
plugins will make little sense.

> * .la files MUST NOT move to a subdirectory of the multiarch directory;
> http://wiki.debian.org/ReleaseGoals/LAFileRemoval will eventually make this
> irrelevant
> [rationale: earlier in the thread, Goswin explained that this doesn't work]

Or at least is untested. Given the release goal it seems pointless to
care. But as long as you have an .la file and that must be in /usr/lib
the -dev package can not be Multi-Arch: same, which is not a problem.

> * architecture-specific header files currently found in /usr/lib (on my
> system: D-Bus, GLib, Gtk, ejabberd) MUST NOT move to a multiarch directory
> [rationale: Policy doesn't yet say they can]

I disagree there.

| 9.1.1 File System Structure
|...
| Applications may also use a single subdirectory under
| /usr/lib/triplet.

I believe that means anything that is allowed in /usr/lib/package/ is
also allowed in /usr/lib/triplet/package/.

MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.

> * miscellaneous architecture-specific non-library data (pkg-config .pc files)
> MUST NOT move to a multiarch directory
> [rationale: Policy doesn't yet say they can]

Again I disagree. I don't think policy is blocking here. The problem is
pkg-config supporting it. Fix for pkg-config pending? (see other mail in
this thread)

MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.

> In each case where I'm wrong, could you please explain whether putting those
> files in multiarch directories is currently forbidden, discouraged, encouraged
> or recommended?
>
> For autotools packages that hard-code paths, usually because they have plugins
> (gtk-2.0 is a good example), the only reliable way to divert the runtime
> library into /usr/lib seems to be to use `./configure --libdir=TRIPLET`,
> which means that files destined for any directory of the form ${libdir}/foo
> will get diverted too, even if current Policy forbids this. Should maintainers
> be using --libdir and then moving forbidden files (e.g. pkg-config files)
> back to the arch-neutral location, or encouraging upstreams to provide
> more --whateverdir switches, or what?
>
> A concrete example: if I understand correctly, Goswin suggests I use --libdir
> on dbus, to make it more exemplary, and in particular not misleading for
> maintainers of packages that do hard-code paths. However, I would then need
> to move the .pc file and the arch-specific header back out of the multiarch
> directory to comply with what you said, editing the .pc file to have the
> right path for the arch-specific header in the process, unless I patch
> configure.ac to add some sort of --archincludedir option, autoreconf, and
> use that option.

With the exception of .la and .pc files I do not think that moving the
files is harmfull nor that policy forbids it (see 9.1.1). And they need
to move there eventually anyway (or to /usr/include/triplet/). Further
the files move there naturally when you set --libdir and one must set
--libdir=/usr/lib/$(DEB_HOST_GNU_TYPE) for plugins.

Overall it makes no sense not to move the files with the exception of
*.la and *.pc files. Setting --libdir will set the correct paths in *.la
and *.pc files too and they themself can be moved back safely. Patching
configure.ac would just be wasted in the long run. If policy forbids
this then policy needs to be changed instead of patching thousands of
sources.

> Regards,
> Simon

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org