[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Library package naming

Roger Leigh <rl117@york.ac.uk> writes:

> 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.

I'm sorry if my reply was a bit terse--I'm just a bit annoyed with
upstream (who just plain ignore my patches--even an outright rejection
would be better).

Is it common or good practice to keep the build for Debian separate
for upstream, or should I really get my changes incorporated upstream
first?  It's just that I don't really see this happening all that soon
(it at all).

Would the following scheme be acceptable to you?:

Package: libijs-0.34
contains libijs-0.34.so

Package: libijs-0.34-dev
Provides: libijs-dev
Conflicts: libijs-dev
contains libijs.a and ijs-config

This will allow versioned Build-Depends.  If there are regular
releases, then the numbers of conflicts in the -dev package will get
quite long.  Should I keep them indefinitely?

It occurs to me that I could achieve exactly the sort of
build-dependency that you require simply by putting the static library
in a versioned package name and build-depending on that, without
requiring and shared library (although it would be ususual, and if I'm
going to that trouble, I may as well make it shared).


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: