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

Re: JPEG 8 transition



On Mon, Mar 15, 2010 at 01:03:19AM +0100, Julien Cristau wrote:
> On Mon, Mar 15, 2010 at 00:29:45 +0100, Bill Allombert wrote:
> 
> > On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote:
> > > * Sune Vuorela (nospam@vuorela.dk) [100214 21:32]:
> > > I fear I need to agree with you. We should have libjpeg62 with
> > > symbols, recompile every package build-depending on libjpeg*-dev after
> > > that till the release, and then move to libjpeg8 (or whatever it is)
> > > at the begining of the squeeze+1-cycle (and we can be sure nothing
> > > breaks because of the symbols).
> > 
> > Ok so I have experimented with a libjpeg62 source with versionned symbols,
> > It works fine but for an annoying problem:
> > 
> Bill, see <slrnhni28d.nfa.nospam@sshway.ssh.pusling.com>.  It doesn't
> look like there's any way we can switch gtk and qt to libjpeg8 while
> (non symbol versioned) libjpeg62 is mandated by LSB (unless we decide to
> ignore the LSB).

I do not think this is technically true. For example a program
linked with Qt-linked-with-libjpeg62 should work fine when used with
Qt-linked-with-libjpeg8 because LSB-mandated Qt interface does not
export the raw libjpeg interface to the program. The same is true for
gtk.

However this would probably break some binary-only software that are
not strictly LSB compliant.

So I am considering the following transition plan:

1) We transition to libjpeg62+versioned-symbol (libjpeg62vs  for short)
for squeeze. This should not break the LSB except maybe for the warnings
I mentionned above, but this is a minor issue.

2) We should be able to get other distributions to follow suite and the
LSB to be updated to require libjpeg62vs. Since both forward and
backward compatibility is preserved, and versioned symbols are
technically superior, this should be possible.

3) Once some binary-only softwares have been rebuild against libjpeg62vs, then
it should be safe to move to libjpeg8.

Is there a better plan ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

Attachment: signature.asc
Description: Digital signature


Reply to: