Conflicting library names

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Conflicting library names

Kari Pahula-2
I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657).
The latter is rather unfortunately named.  The namespace of two letter
acronyms is rather crowded and there is already a /usr/lib/libsl0 in
libsl0-heimdal.

What would be a sane way to handle this situation?  I'm thinking of
just copying libsl into the package and linking statically to it and
to not package libsl at all.  IMHO there are already quite a lot of
libraries in Debian that provide utilities such as linked lists for C
programmers.

Most of the uses of libsl are internal in libggtl, but some parts of
its API return libsl derived data structures.  There would be some
need to have libsl at hand for users...  Otherwise I would just take
the easy road and not bother packaging libsl at all.

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Conflicting library names

Justin T Pryzby-2
On Fri, Mar 24, 2006 at 12:54:01PM +0200, Kari Pahula wrote:
> I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657).
> The latter is rather unfortunately named.  The namespace of two letter
> acronyms is rather crowded and there is already a /usr/lib/libsl0 in
> libsl0-heimdal.
To be precise, it is a file collision, not a directory:
  libsl0-heimdal: usr/lib/libsl.so.0
  libsl0-heimdal: usr/lib/libsl.so.0.1.2

> What would be a sane way to handle this situation?  I'm thinking of
> just copying libsl into the package and linking statically to it and
> to not package libsl at all.
The obvious disadvantage to this is that the source package will be
nonpristine (well, unless you use an embedded-style source package,
which is like borderline-pristine or something).

> Most of the uses of libsl are internal in libggtl, but some parts of
> its API return libsl derived data structures.  There would be some
> need to have libsl at hand for users...  Otherwise I would just take
> the easy road and not bother packaging libsl at all.
Perhaps you could install include files, including any from libsl, to
/usr/include/ggtl/ (rather than cause more 2 letter collisions), and
rename the library file to libggtl-sl?  (And update the soname too of
course).

This means that some binaries won't run on different distributions,
but there's no way around that anyway, right?

Justin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]