Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> On Sun, Mar 14, 2010 at 09:42:58PM +0100, Philipp Kern wrote:
>> We would like to know what needs attention, what bugs still need to be
>> fixed in your package before squeeze is released, which features or new
>> upstream versions you want to see in squeeze which are not ready yet.
>> Furthermore we would like to get an overview of the remaining transitions
>> that need to be done.
> I like to point your attention to the libjpeg8 transition. I have no
> problem deferring the libjpeg8 transition to squeeze+1, but we should
> have a clear plan for this transition before the freeze so at least
> libjpeg62 can be ajusted to make the transition to libjpeg8 less
> painful.
We are not comfortable with switching to libjpeg8 before the release. In
fact, it seems we cannot stay LSB-compatible at all if we switch the
major desktop environments and their base libs to libjpeg8, no matter
what we do with libjpeg6 [1]. We need to discuss (probably on -project?)
if LSB-compatibility is something Debian actually cares about, and if
yes, how we can achieve it while not ignoring modern software. It would
be happy if you could start this discussion, because I fear that I don't
have the time to write up a piece explaining the different problems of
this case.
> I'd like to use this opportunuity to apologize for the trouble I caused with
> libjpeg8. I was so afraid that packages would FTBFS with libjpeg8 that I
> ignored the other failure mode.
Thanks. I have to admit that the release team (or other people, for that
matter) did not really foresee the problems of this particular
transition :-/
Marc
Footnotes:
[1] Because third party application are mostly built against
a lib with unversioned symbols, we would end up with a situation
where two libs in the same namespace provide versioned symbols, an
application uses unversioned symbols and breakage is common.
--
BOFH #315:
The recent proliferation of Nuclear Testing
Attachment:
pgp_dyOkuXz7j.pgp
Description: PGP signature