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....@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ý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405844610.26281.143567797.5d6ac...@webmail.messagingengine.com

Reply via email to