Junichi Uekawa <[EMAIL PROTECTED]> writes: > Roger Leigh <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
