Mail Archives: cygwin/2006/11/29/23:14:17
LIM Fung-Chai wrote:
> In a way, this is a bug report of sort, for the cygwin jbigkit maintainer.
Not a bug.
> The libjbig2 cygwin package is built from the upstream jbigkit package
> (http://www.cl.cam.ac.uk/~mgk25/jbigkit/), which implements a codec
> adhering to the JBIG1 standard. The "2" in libjbig2 gives the
> impression that it supports the JBIG2 format,
You infer where I did not imply.
> which, being newer than
> JBIG1, gives better compression than JBIG1. It should have retained
> the older moniker "libjbig1".
No, it should not have retained the old number; your impression is
wrong: the "2" is a DLL API version number, not a format version number.
If I didn't change the DLL API version number when the API was, in
fact, changed in a backwards-incompatible way, then existing
applications would break. The API change was described in the release
announcement
http://cygwin.com/ml/cygwin-announce/2006-11/msg00048.html
* Bump DLL number because upstream API changed:
"minor API modification in jbg_enc_options(): parameter l0 changed
from type long to unsigned long; previous value now remains
unchanged when l0 == 0 (was: l0 < 0)"
Existing client code MAY have, in the past, tried to pass negative
values in position #10 to jbg_enc_options() since that was a "change the
other encoding options but do not change #10". However, with this API
change those existing calls with parameter #10 < 0 would get silently
reinterpreted as "parameter #10 is a really big number" and WOULD cause
the corresponding jbg_enc_option to be changed.
Therefore, old code should not use the new DLL without recompiling --
and the only way to force that to happen is to change the DLL name.
(And, old client code that relied on the "negative value means don't
modify" behavior would elicit a warning message during the recompile, so
that's good too).
So, we've established that:
(1) this is an incompatible API change
(2) on windows, we change the DLL name when the API changes, by
incrementing the API version number.
cygjbig1.dll -> cygjbig-2.dll
(The hyphen was because jbig-1.6's build process now uses libtool, and
the libfoo-${DLLNUM}.dll pattern is libtool's naming convention. I
trust you're not going to try to argue that
cygjbig1.dll -> cygjbig-1.dll
is somehow *less* confusing? And if so, then how would the two cygwin
packages containing those DLLs be named? And what of the NEXT
incompatible API change in jbigkit -- what should THAT dll and package
be named?)
(3) the cygwin packaging scheme requires that, for a DLL named
'cyg{PKG}-{DLLNUM}.dll' or 'cyg{PKG}{DLLNUM}.dll'
the package containing that DLL should be named
'lib{PKG}{DLLNUM}'
which, in this case, is libjbig2.
(Now you see the problem with cygjbig1.dll -> cygjbig-1.dll.
Both DLLs *should* go into a package named "libjbig1". That's
a problem.)
If that conflicts with some other package NOT currently part of the
cygwin official distribution, nor even proposed for official inclusion,
and whose source code has been downloaded from sourceforge by all of 250
people in the entire world, and perhaps confuses someone who didn't read
the release announcement first...
well, that's not a problem I can solve.
> FYI: An open-source implementation of a JBIG2 decoder is part of the
> ghostscript project and is described in
> http://jbig2dec.sourceforge.net/. Google has sponsored an open-source
> JBIG2 encoder, see http://www.imperialviolet.org/jbig2.html.
If someone were to propose a JBIG2 package for official inclusion, I
would suggest the following naming scheme for the packages:
The jbig2dec package builds a library named "libjbig2dec" not
"libjbig*", so:
jbig2dec
libjbig2dec-devel
libjbig2dec{DLLNUM} XXXX scratch that, jbig2dec doesn't build
as a shared library anyway; it's static
only. So there's no conflict here.
(And, even if jbig2dec DID build a shared library, package name
"libjbig2decX" doesn't conflict with package name "libjbig2" anyway.)
The jbig2enc package builds a library named "libjbig2enc" not
"libjbig*", so:
jbig2enc
libjbig2enc-devel
libjbig2enc{DLLNUM} XXXX again, scratch that. jbig2enc builds
only a static lib. So again, no
conflict.
(And, even if jbig2enc DID build a shared library, package name
"libjbig2encX" doesn't conflict with package name "libjbig2" anyway.)
So, as there is no technical conflict nor any true packaging conflict,
the ONLY concern here is that some people might be confused by the name
of the package containing cygjbig-2.dll, libjbig2-1.6-1.
Uhmmm...how shall I put this? Solving that "problem" rates lower on my
priority list than organizing my collection of pocket lint. I've
already spent all the time I'm willing to devote to that issue,
composing this email.
--
Chuck
jbigkit maintainer for cygwin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -