Roger Leigh <[EMAIL PROTECTED]> 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).
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]
