Bug#754988: transition: libjpeg-turbo
And the packaging result is sitting in NEW, quietly waiting to be
uploaded
to experimental.
The git repository has been pushed, so if you are impatient, you can
build
it from there.
O.
On Sun, Jul 20, 2014, at 10:23, Ondřej Surý wrote:
> 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
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: