Re: Debian policy update (3.8.4.0)
Tollef Fog Heen tfh...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
Simon McVittie s...@debian.org writes:
Steve Langasek wrote:
On Mon, Feb 01, 2010 at 11:17:19PM +, 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
Re: Debian policy update (3.8.4.0)
Simon McVittie s...@debian.org writes:
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.
You can move headers, the *.so link and static libs. But .pc and .la
files can not be in the triplet dir yet afaik. So that is a no go for
now. But if you want you can try and see what changes libtool and
pkgconfig would need for this.
It'd be somewhat more complex to rearrange things for a multiarch -dev
package,
but could be done; I assume the recommended way to do that would be to use
./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}?
How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently?
Currently, with dh_install - libdbus happens to not hard-code paths, and thus
work correctly when it's just moved around (Michael already moved it from
/usr/lib to /lib for Upstart's benefit, so this definitely does work). I
realise this doesn't generalize to all libraries, in particular those that
hard-code paths (generally to load plugins, like you said).
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).
Maybe that is documented in gcc somewhere.
For packages like libdbus that already split out arch-dep headers to ${libdir}
there doesn't seem any point in trying to override that, but for packages
that don't necessarily make sure their headers are arch-indep, would it be
appropriate to use --includedir=/usr/include/triplet, i.e. pessimistically
assume that every header is arch-specific?
I believe so. /usr/include/triplet is at least preferable to
/usr/lib/triplet/package/include as the former is in the default include
path and works without -I option.
In particular, generic tools that run configure automatically, like
dh_auto_configure and cdbs, would probably have to assume that every package
contains arch-specific headers unless told otherwise; am I right?
I would rather assume the opposite, that headers are arch independent
and dpkg will then makes sure of that during install at the latest. So
while the assumption might be wrong it is not dangerous.
(Some concrete examples: GLib and GDK also have one arch-specific header in
${libdir} each; expat is one of several with a version of config.h in
/usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
Most of /usr/lib/glib-2.0/include/glibconfig.h is already arch
independent or can trivialy be rewritten as such using C99. Imho that
would be preferable. But short of that those have to go into a triplet
dir eventually. The common theme here seems to be that it is *config.h
as generated by configure. Maybe some automatism can be added to
autoconf/automake to automatically put such files into
/usr/include/triplet.
As said, developement packages still need work to figure out the best
practices and adjust the toolchain. So for now keep them as is.
Regards,
Simon
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
]] 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.
| For packages like libdbus that already split out arch-dep headers to ${libdir}
| there doesn't seem any point in trying to override that, but for packages
| that don't necessarily make sure their headers are arch-indep, would it be
| appropriate to use --includedir=/usr/include/triplet, i.e. pessimistically
| assume that every header is arch-specific?
Given that the only cost is disk space, I think that's a tradeoff that
makes sense.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
On Mon, Feb 01, 2010 at 11:17:19PM +, 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian policy update (3.8.4.0)
Steve Langasek wrote:
On Mon, Feb 01, 2010 at 11:17:19PM +, 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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
(Please cc me on this thread, I'm not subscribed to debian-devel.)
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.
It'd be somewhat more complex to rearrange things for a multiarch -dev package,
but could be done; I assume the recommended way to do that would be to use
./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}?
libdbus is probably an interesting example if you want to do that because it
has one architecture-dependent header file, which it places in ${libdir}, and
keeps the rest of /usr/include architecture-independent.
For the actual change I made, please see pkg-utopia svn or this commit mail:
http://lists.alioth.debian.org/pipermail/pkg-utopia-commits/2010-January/003534.html
The -dev package currently contains:
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libdbus-1-dev
/usr/share/doc/libdbus-1-dev/AUTHORS [and other docs]
/usr/lib
/usr/lib/libdbus-1.a
/usr/lib/pkgconfig
/usr/lib/pkgconfig/dbus-1.pc
/usr/lib/dbus-1.0
/usr/lib/dbus-1.0/include
/usr/lib/dbus-1.0/include/dbus
/usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h
/usr/include
/usr/include/dbus-1.0
/usr/include/dbus-1.0/dbus
/usr/include/dbus-1.0/dbus/dbus-bus.h [and other headers]
/usr/lib/libdbus-1.so
There's no .la file.
Development symlink:
lrwxrwxrwx 1 root root 38 Jan 27 23:49 /usr/lib/libdbus-1.so -
/lib/i486-linux-gnu/libdbus-1.so.3.4.0
.pc file:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
sysconfdir=/etc
session_bus_services_dir=/usr/share/dbus-1/services
daemondir=/usr/bin
Name: dbus
Description: Free desktop message bus
Version: 1.2.16
Libs: -L${libdir} -ldbus-1 -lpthread -lrt
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
I'd also be happy to multiarchify libgfshare (a small library using autotools
and debhelper 7) if that would make a useful example of how to do the simple
case; it's in collab-maint bzr, and you're welcome to commit there if that
would help. I'd also be happy to migrate it to collab-maint git (which
I've considered doing anyway) if that's easier for you to deal with.
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
Simon McVittie s...@debian.org writes:
(Please cc me on this thread, I'm not subscribed to debian-devel.)
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.
It'd be somewhat more complex to rearrange things for a multiarch -dev
package,
but could be done; I assume the recommended way to do that would be to use
./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}?
How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently? If
your library uses any plugins then you need to compile it for
/usr/lib/${DEB_HOST_GNU_TYPE} and not just move the files there post
build.
libdbus is probably an interesting example if you want to do that because it
has one architecture-dependent header file, which it places in ${libdir}, and
keeps the rest of /usr/include architecture-independent.
Architecture dependent header files belong under
/usr/include/triplet/
That directory is searched by default in gcc so it works without extra
-I option. Preferable to ${libdir}. But dbus screws that up as well as
it uses a subdir for its files.
.pc file:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
sysconfdir=/etc
session_bus_services_dir=/usr/share/dbus-1/services
daemondir=/usr/bin
Name: dbus
Description: Free desktop message bus
Version: 1.2.16
Libs: -L${libdir} -ldbus-1 -lpthread -lrt
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
Cflags: -I${includedir}/dbus-1.0 -I${includedir}/i486-linux-gnu/dbus-1.0
Would be better but your solution is policy conform too I think.
I'd also be happy to multiarchify libgfshare (a small library using autotools
and debhelper 7) if that would make a useful example of how to do the simple
case; it's in collab-maint bzr, and you're welcome to commit there if that
would help. I'd also be happy to migrate it to collab-maint git (which
I've considered doing anyway) if that's easier for you to deal with.
Regards,
Simon
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
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.
It'd be somewhat more complex to rearrange things for a multiarch -dev
package,
but could be done; I assume the recommended way to do that would be to use
./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}?
How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently?
Currently, with dh_install - libdbus happens to not hard-code paths, and thus
work correctly when it's just moved around (Michael already moved it from
/usr/lib to /lib for Upstart's benefit, so this definitely does work). I
realise this doesn't generalize to all libraries, in particular those that
hard-code paths (generally to load plugins, like you said).
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).
For packages like libdbus that already split out arch-dep headers to ${libdir}
there doesn't seem any point in trying to override that, but for packages
that don't necessarily make sure their headers are arch-indep, would it be
appropriate to use --includedir=/usr/include/triplet, i.e. pessimistically
assume that every header is arch-specific?
In particular, generic tools that run configure automatically, like
dh_auto_configure and cdbs, would probably have to assume that every package
contains arch-specific headers unless told otherwise; am I right?
(Some concrete examples: GLib and GDK also have one arch-specific header in
${libdir} each; expat is one of several with a version of config.h in
/usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
Simon McVittie s...@debian.org writes:
Since libdbus appears in ia32-libs and isn't particularly large, and I
wanted to make an experimental upload anyway (to add a -dbg package
while avoiding the NEW queue blocking unstable), I've prepared a
hopefully multiarch-compatible version of it, which uses
/lib/${DEB_HOST_GNU_TYPE} (libdbus was already in /lib, because Upstart
uses it) and is Multi-Arch: same. Commit mail with a diff:
http://lists.alioth.debian.org/pipermail/pkg-utopia-commits/2010-January/003534.html
Does this look appropriate for experimental? I've held off on uploading for
now in case the multiarch cabal want to block it.
libdbus-1-3 now contains:
/.
/lib
/lib/i486-linux-gnu
/lib/i486-linux-gnu/libdbus-1.so.3.4.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libdbus-1-3
/usr/share/doc/libdbus-1-3/AUTHORS
/usr/share/doc/libdbus-1-3/changelog.gz
/usr/share/doc/libdbus-1-3/copyright
/usr/share/doc/libdbus-1-3/README.gz
/usr/share/doc/libdbus-1-3/changelog.Debian.gz
/lib/i486-linux-gnu/libdbus-1.so.3
Regards,
Simon
Looks fine from here. How does your -dev package look? The .so link, .la
and .pc files (if any) are specifically important.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
Since libdbus appears in ia32-libs and isn't particularly large, and I
wanted to make an experimental upload anyway (to add a -dbg package
while avoiding the NEW queue blocking unstable), I've prepared a
hopefully multiarch-compatible version of it, which uses
/lib/${DEB_HOST_GNU_TYPE} (libdbus was already in /lib, because Upstart
uses it) and is Multi-Arch: same. Commit mail with a diff:
http://lists.alioth.debian.org/pipermail/pkg-utopia-commits/2010-January/003534.html
Does this look appropriate for experimental? I've held off on uploading for
now in case the multiarch cabal want to block it.
libdbus-1-3 now contains:
/.
/lib
/lib/i486-linux-gnu
/lib/i486-linux-gnu/libdbus-1.so.3.4.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libdbus-1-3
/usr/share/doc/libdbus-1-3/AUTHORS
/usr/share/doc/libdbus-1-3/changelog.gz
/usr/share/doc/libdbus-1-3/copyright
/usr/share/doc/libdbus-1-3/README.gz
/usr/share/doc/libdbus-1-3/changelog.Debian.gz
/lib/i486-linux-gnu/libdbus-1.so.3
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
Le mercredi 27 janvier 2010 à 21:44 +0100, Bill Allombert a écrit : Dear developers, Debian policy 3.8.4.0 has been uploaded today with the following changes: * An FHS exception has been granted for multiarch libraries. Permitting files to instead be installed to `/lib/triplet' and `/usr/lib/triplet' directories. [9.1.1] Does that mean we can start working on multiarch-compatible packages right now, or would it be a waste of time? Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian policy update (3.8.4.0)
Hi, 2010/1/27 Josselin Mouette j...@debian.org: Le mercredi 27 janvier 2010 à 21:44 +0100, Bill Allombert a écrit : Dear developers, Debian policy 3.8.4.0 has been uploaded today with the following changes: * An FHS exception has been granted for multiarch libraries. Permitting files to instead be installed to `/lib/triplet' and `/usr/lib/triplet' directories. [9.1.1] Does that mean we can start working on multiarch-compatible packages right now, or would it be a waste of time? Why should it be a waste of time? It only means you are allowed to work on multiarch packages, this step helps multiarch developers and testers to do a better job having real test cases in the archive. Beware there is still lack of support for several tools like dpkg/apt within Debian. Regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
On Wed, Jan 27, 2010 at 09:59:00PM +0100, Josselin Mouette wrote: Le mercredi 27 janvier 2010 à 21:44 +0100, Bill Allombert a écrit : Dear developers, Debian policy 3.8.4.0 has been uploaded today with the following changes: * An FHS exception has been granted for multiarch libraries. Permitting files to instead be installed to `/lib/triplet' and `/usr/lib/triplet' directories. [9.1.1] Does that mean we can start working on multiarch-compatible packages right now, or would it be a waste of time? It means that packages may begin installing their files in the multiarch directories. The draft multiarch spec is not part of Policy yet, nor is there a package manager that will successfully cross-install these, so I wouldn't encourage maintainers to have their packages declare themselves Multi-Arch: yes without careful coordination with debian-devel. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
