FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-27-2010, 07:59 PM
Josselin Mouette
 
Default 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
 
Old 01-27-2010, 08:40 PM
Hector Oron
 
Default Debian policy update (3.8.4.0)

Hi,

2010/1/27 Josselin Mouette <joss@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,
--
Hctor Orn

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-27-2010, 08:49 PM
Steve Langasek
 
Default 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 01-29-2010, 01:18 AM
Simon McVittie
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-29-2010, 10:33 AM
Goswin von Brederlow
 
Default Debian policy update (3.8.4.0)

Simon McVittie <smcv@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2010, 01:29 PM
Simon McVittie
 
Default 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=unixath=/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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2010, 06:46 PM
Goswin von Brederlow
 
Default Debian policy update (3.8.4.0)

Simon McVittie <smcv@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=unixath=/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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-01-2010, 10:17 PM
Simon McVittie
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 12:22 PM
Goswin von Brederlow
 
Default Debian policy update (3.8.4.0)

Simon McVittie <smcv@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 07:18 PM
Tollef Fog Heen
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org