Bug#754988: transition: libjpeg-turbo
Hi Emilio,
On Sat, Jul 19, 2014, at 00:11, Emilio Pozuelo Monfort wrote:
> Hi Ondřej, thanks for this report.
>
> On 16/07/14 17:47, Ondřej Surý wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: transition
> >
> > As voted by tech-ctte in #717076, we are going to prepare the
> > transition from IIJ jpeg to libjpeg-turbo implementation.
> >
> > The transition plan as asked in the resolution:
> >
> > 1. Since nothing depends on libjpeg8 API we will bump back to
> > libjpeg.so.62 with extra "decode from memory buffer" interface
> > (jpeg_mem_src/jpeg_mem_dest).
> >
> > NOTES:
> > * Fedora/OpenSUSE has also settled down on libjpeg.so.62, so that
> > would make us cross-distro compatible.
> >
> > * Ubuntu has already transitioned to libjpeg-turbo8, so it will be
> > up to them if they bump back to libjpeg62.
> >
> > 2. The proposed libjpeg-turbo packages implementing libjpeg62 will be
> > uploaded to experimental before end of July 2014. We will announce
> > that to debian-devel and leave a reasonable period of time for
> > people to test their packages to recompile against libjpeg-turbo.
> >
> > I propose we provide libjpeg-dev dummy (not virtual) package in
> > experimental, so there's no clash between libjpeg8-dev and
> > libjpeg-turbo-dev.
> >
> > 3. The updated libjpeg-turbo packages implementing libjpeg62 and
> > libjpeg-turbo-dev (providing libjpeg-dev virtual package) will be
> > uploaded to unstable at the end of August 2014. This upload will
> > be synchronized with libjpeg8 maintainer (or NMUed) to remove
> > virtual libjpeg-dev from libjpeg8-dev at the same time (or very
> > close to it).
> >
> > Cheers,
> > Ondrej
> >
> > Ben file:
> >
> > title = "libjpeg-turbo";
> > is_affected = .depends ~ "libjpeg8" | .depends ~ "libjpeg62";
> > is_good = .depends ~ "libjpeg62";
> > is_bad = .depends ~ "libjpeg8";
>
> There already is a libjpeg62 package, built from src:libjpeg6b. What's
> the plan here? Drop src:libjpeg6b? Take over the libjpeg62 name and
> rename current libjpeg62 to libjpeg62-ijg, and make it Provide and
> Conflict libjpeg62?
> Something else?
Somehow I didn't realize that we still have libjpeg6b in the archive.
Dropping/Replacing src:libjpeg6b makes most sense to me and I can
probably do that from src:libjpeg-turbo (epoch would need to be
introduced anyway to replace IIJ JPEG packages).
dak also shows that it should not be a problem:
Checking reverse dependencies...
# Broken Depends:
ecere-sdk: libecere0 [amd64 armel armhf i386 mips mipsel powerpc]
emacs23: emacs23 [hurd-i386]
emacs23-lucid [hurd-i386]
lsb: lsb-desktop
# Broken Build-Depends:
eagle/non-free: libjpeg62-dev
ecere-sdk: libjpeg62-dev
emacs23: libjpeg62-dev
Those looks more like relicts than real depends.
> I'm especially interested in knowing whether libjpeg-turbo will be able
> to migrate before anything else does (i.e whether it will be a smooth
> transition) but until I fully understand what packages there will be, and
> what conflicts, I can't know that.
I do think so. I will prepare update libjpeg-turbo packages in
experimental
during next week and let you know to review the changes.
Ondrej
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: