Re: Library package naming
Junichi Uekawa <dancer@netfort.gr.jp> writes:
> Roger Leigh <rl117@york.ac.uk> immo vero scripsit:
>
> > However, the value of having a shared library at this point in time is
> > doubtful. gimp-print will Build-Depend on it, and possibly hpijs, but
> > I don't think there will be many other users. I don't think that the
> > effort of packaging it as a shared library is worth the benefits right
> > now. The library is tiny, so it isn't going to gain much in reduced
> > memory usage.
>
> Don't underestimate the significance of a shared library in
> Debian.
When every release is binary-incompatible with the last (different
SONAME) I can't see that it can cause problems, unless you are
referring to build dependencies. When the ABI changes so fast, I have
no desire to bolt-on versioning unsupported by upstream.
> > I think I will use Sean's suggestion and have a static-only ijs-dev,
> > and once the specification and ABI are stable I will then make it
> > shared.
>
> I really doubt you've read my notes enough, but anyway.
> Make sure it doesn't get released in stable.
I hadn't at the time I wrote my reply. I have now, but it really
hasn't helped that much: I have already packaged shared libs for
Debian (libgimpprint, using both -release and -version-info for the
development and stable series respectively) and I have quite a bit of
experience with libtool and library versioning.
> Whatever it is, and however much you claim it is an unstable ABI,
> if it gets released as a "stable" Debian release,
> it will be stable for a long time.
If you look at the packaging I have done
(http://www-users.york.ac.uk/~rl117/ijs/) then you will see that the
upstream source consists of:
- a simple minimal configure script
- a single simple Makefile
When I packaged it I
- rewrote the build to use autoconf2.5x, automake 1.6 and libtool.
- added the framework for ABI versioning, and the options of
versioning with -release or -version-info
- added an ijs-config script (replaces the one they provide, this
one is generated entirely from configure)
- added an ijs.pc file for pkg-config use
- added an AM_PATH_IJS macro for autoconf use
The last three all use custom m4 macrocode I wrote (available in the
ac-archive, renamed and specialised for use in ijs). Due to the
unstable nature of the source, I defaulted to -release versioning, and
disabling shared libraries by default, but the framework was in place
for the future when they have a stable series of releases.
The upstream do not want any of these changes. I can't maintain them
as a patch or include them in Debian because then the Debian version
of IJS will be different from every other. It's also going to be very
time-consuming and dificult.
I could provide it versioned with -release $(VERSION), but this would
still mean maintaining a completely separate build from upstream. I
could keep just my autoconf/make/libtool changes and forget the rest,
but this will still mean finding and merging every single build change
into my scripts. If I provide it as a single static library, I can
use their scripts, even though they are vastly inferior to my own.
I don't yet know what the objections they have to libtool are, but if
you have any suggestion as to how I can deal with this, I would be
very grateful.
Regards,
Roger
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
--
To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: