Re: JPEG 8 transition

[Andreas Barth <aba@not.so.argh.org>]

* Sune Vuorela (nospam@vuorela.dk) [100214 21:32]:
> On 2010-02-14, Andreas Barth <aba@not.so.argh.org> wrote:
> >> So I will state it a last time:
> >> I propose to upload the libjpeg6b source package that generate 
> >> libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload 
> >> libjpeg8 source package that generate a libjpeg8-dev that provides
> >> both libjpeg62-dev and libjpeg-dev. 
> >> Do the release team want me to do that ?
> >
> > We first want to have the crashes fixed. Which even might be an
> > rollback. After we have found out what do do, we can continue
> > discussing that.

> As stated by Pierre several months ago, loading both into the same
> process is a recipe for disaster. And it is going to be seen very much
> in KDE when qt is rebuilt, but kde libraries isn't.
> 
> libkhtml.so.5 links libjpeg. libkhtml is used in many places, including
> most times when you want to render html. It is often used as a plugin
> thru the kpart technology, meaning that it is available in most KDE
> apps.
> 
> libQtGui.so.4 is using libjpeg thru
> /usr/lib/qt4/plugins/imageformats/libqjpeg.so to load jpg images
> wherever needed, and it is happening in many places.
> 
> AS long as both links the same libjpeg, everything is fine. Wehn they
> use different libjpeg, hard to track down crashes.
> 
> I currently think roll-back, doing things properly, going ahead, is the
> way forward.

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

If we don't roll-back, we need to have breaks from libjpeg8 to every
package which links to libjpeg62. This is possible, but ugly, and
would make the upgrade harder (and as Julien said "this is what symbol
versions are for", so let's use them).


In other words, please rollback libjpeg-dev to point again to
libjpeg62-dev, and add symbol versions to libjpeg62 (the second can
happen later, but as sooner it happens the better it is). After
libjpeg-dev points again to libjpeg62-dev, we need to binNMU all
affected programs.



Cheers,
Andi