[RFC] jpeg library

[Yaakov (Cygwin/X)]

On 28/06/2009 01:17, Charles Wilson wrote:
> You mean for clients that aren't naughty, and do not/never did access
> these "private" fields?  None, as far as I can tell.  The *size* of the
> struct doesn't change. Only the names of some of the fields (not their
> type), and their meaning.  Some purely internal structs change
> significantly, but that shouldn't affect external clients, even naughty
> ones.
>
> Although the actual strings associated with various error code numbers
> changes, so that could lead to some surprising incorrect error messages
> until clients are recompiled.
>
> In any event, if I release a new cygjpeg-62.dll (same as current name)
> without the lossless jpeg patch, and it DOES break everything in sight,
> well then, I'll withdraw it and we'll go with the plan B transition.

That should be easily verified with a bit of testing on everyone's part, 
*before* the release.

> Well, "test" release, sure.  But given the interlocking dependencies of
> libraries (esp. graphics libraries), you'd need an ever-increasing
> number of these libraries in pending/test state. I don't have the
> bandwidth to manage that outside of the sourceware facilities.  Since we
> have a perfectly good mirror system and "test status" already available
> for such things...

If there is indeed no ABI breakage in the normal case, there shouldn't 
be any need for a bunch of packages in testing; everyone just tests the 
new libjpeg62, and if their package(s) still work, nothing more to do, 
right?

> Well, with 1.7 due out sometime in the next week or so, I really don't
> want to destabilize that.

That shouldn't stop you from a test: version ASAP.

> Yeah, but on the other hand, every distro out there has a stack of
> patches for libjpeg, because upstream is dead but the code has bugs.
> Thus, debian has a list of libjpeg patches that, for all intents and
> purposes, they must now "maintain in perpetuity".

True; thankfully the Linux distros are doing the hard work for us. :-)

> But this isn't a "pseudo-incompatibility" caused by a simple switch to
> gcc4/shared-libgcc. This is a real ABI violation we're contemplating.
> It's exactly what DLL version number bumps are FOR.

Freetype went through a similar transition some time ago[1]: they used 
to expose many internal symbols and headers, and before 2.2.0 they 
stopped.  Interestingly, they didn't change the ABI number, since the 
only changes were to things supposed to be internal.  Everyone fixed 
their packages (and the FT devs did help provide packages), and life 
moved on.

[1] http://freetype.sourceforge.net/freetype2/freetype-2.2.0.html


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple