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 03-17-2009, 09:42 AM
Enrico Zini
 
Default Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 10:17:37AM +0000, Enrico Zini wrote:

> I would like to get to the point of uploading #519184. However I have
> one issue on which I'm unsure: the library API and ABI would be stable
> enough, but upstream is not building or supporting shared libraries yet.
> Last time I asked, he had some libtool problem in some obscure
> architecture and no time to investigate on it.
>
> Here are the possible options that I could think of:
>
> 1. Patch the package to build a shared library; I already have the
> patch prepared and working. What version should I pass to libtool?
> 0:0:0 is quite obvious, and hopefully when upstream will get to
> shared libraries he will pick a higher one, but what if upstream
> will break API or ABI once or several times before starting to
> support shared libraries? This is unlikely, but it cannot be
> assumed to be impossible.

After some suggestions by Sune Vuorela on IRC, point 1 can be expanded:

- call the shared library package libgribapi0d, adding the extra d to
signify that it is a Debian specific shared library: that way, the
name a future library provided by upstream will not conflict
- at that point, I can do what I want with libtool versioning, starting
at 0:0:0 and updating as needed as new versions progress

> 2. Package a -dev only package compiled with -fPIC, so that .so
> language bindings can still link to it

I'll pick 1 unless I get significant objections.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
 
Old 03-17-2009, 02:03 PM
Simon Huggins
 
Default Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 10:42:37AM +0000, Enrico Zini wrote:
> On Tue, Mar 17, 2009 at 10:17:37AM +0000, Enrico Zini wrote:
> > I would like to get to the point of uploading #519184. However I have
> > one issue on which I'm unsure: the library API and ABI would be stable
> > enough, but upstream is not building or supporting shared libraries yet.
> > Last time I asked, he had some libtool problem in some obscure
> > architecture and no time to investigate on it.
> I'll pick 1 unless I get significant objections.

Is there a reason you need this now and can't wait until you've managed
to argue for the shared library from upstream and cajoule them into
producing a .so?

I had an upstream that wasn't very confident with soname changes and
went through a long process explaining that and the benefits but
ultimately it was worth it.

--
_ huggie@earth.li -+*+- fou, con et anglais _
(_) debian-legal "consensus" is worth approximately all of the (_)
(_) lint currently residing in my belly button. -- Brian Nelson (_)
\___ ___/
 
Old 03-17-2009, 04:04 PM
Michael Banck
 
Default Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 10:42:37AM +0000, Enrico Zini wrote:
> - call the shared library package libgribapi0d, adding the extra d to
> signify that it is a Debian specific shared library: that way, the
> name a future library provided by upstream will not conflict
> - at that point, I can do what I want with libtool versioning, starting
> at 0:0:0 and updating as needed as new versions progress

Last time I looked at this, it seemed pretty obscure how to tell libtool
to use a soname constructed like that (i.e. libfoo.so.0d), but maybe I
was looking at the wrong places.


Michael


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-17-2009, 07:53 PM
Roger Leigh
 
Default Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 06:04:10PM +0100, Michael Banck wrote:
> On Tue, Mar 17, 2009 at 10:42:37AM +0000, Enrico Zini wrote:
> > - call the shared library package libgribapi0d, adding the extra d to
> > signify that it is a Debian specific shared library: that way, the
> > name a future library provided by upstream will not conflict
> > - at that point, I can do what I want with libtool versioning, starting
> > at 0:0:0 and updating as needed as new versions progress
>
> Last time I looked at this, it seemed pretty obscure how to tell libtool
> to use a soname constructed like that (i.e. libfoo.so.0d), but maybe I
> was looking at the wrong places.

You can't; libtool is only set up to x.y.z integer versioning, or
by adding a suffix to the library name (libfoo-0d.so), using
-version-info and -release, respectively.
That said, I've never tried to set the last digit to a non-integer
value using the former method.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 03-18-2009, 10:42 AM
Enrico Zini
 
Default Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 03:03:22PM +0000, Simon Huggins wrote:

> Is there a reason you need this now and can't wait until you've managed
> to argue for the shared library from upstream and cajoule them into
> producing a .so?
> I had an upstream that wasn't very confident with soname changes and
> went through a long process explaining that and the benefits but
> ultimately it was worth it.

Upstream will not be able to tackle shared libraries before an
unpredictable amount of time, which could easily exceed one year or two.
I am trying to help by sending him an up-to-date version of my libtool
patch after every release, and making myself available for any other
help that would be needed. However, he is not evil; he has other much
more urgent things to work on.

In the meantime, should I:

- not package the library, which is however very useful, and needed by
other software that I have written and want to package
- package the library only as a -dev built with -fPIC (but no one has
endorsed that option so far)
- package a debian-only shared library, taking advantage of the fact
that API and ABI are rather stable, and have been for a year. In
that case, I need to figure out the best way to do it.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
 
Old 03-18-2009, 01:14 PM
Adeodato Simó
 
Default Packaging a library when upstream does not build a .so

* Enrico Zini [Wed, 18 Mar 2009 11:42:58 +0000]:

> On Tue, Mar 17, 2009 at 03:03:22PM +0000, Simon Huggins wrote:

> > Is there a reason you need this now and can't wait until you've managed
> > to argue for the shared library from upstream and cajoule them into
> > producing a .so?
> > I had an upstream that wasn't very confident with soname changes and
> > went through a long process explaining that and the benefits but
> > ultimately it was worth it.

> Upstream will not be able to tackle shared libraries before an
> unpredictable amount of time, which could easily exceed one year or two.
> I am trying to help by sending him an up-to-date version of my libtool
> patch after every release, and making myself available for any other
> help that would be needed. However, he is not evil; he has other much
> more urgent things to work on.

> In the meantime, should I:

> - not package the library, which is however very useful, and needed by
> other software that I have written and want to package
> - package the library only as a -dev built with -fPIC (but no one has
> endorsed that option so far)
> - package a debian-only shared library, taking advantage of the fact
> that API and ABI are rather stable, and have been for a year. In
> that case, I need to figure out the best way to do it.

I think you should go for #3, package a shared library with a Debian
specific SONAME.

My preference would be for libfoo.so.0d, libfoo.so.1d, ... (package
names libfoo0d, libfoo1d, ...), but it’s probably not worth your time to
investigate how to achieve that with libtool, so libfoo-0d.so.0,
libfoo-1d.so.0, etc., also sound appropriate and easily achieved with
the -release option for libtool as Roger Leigh hinted (keeping
-version-info always at 0:0:0). Package names would be libfoo-0d-0,
libfoo-1d-0, ...

HTH,

--
- Are you sure we're good?
- Always.
-- Rory and Lorelai


--
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 09:17 AM.

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