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