Bug#774737: unblock: libjpeg9/1:9a-2
On 2015-01-22 19:15, Bill Allombert wrote:
> On Thu, Jan 22, 2015 at 05:39:46PM +0100, Niels Thykier wrote:
>> Hi Bill,
>>
>> Please forgive me if I misunderstood something; I was not too involved
>> in the libjpeg transition.
>>
>> It is my understanding that there is all utilities / services provided
>> by libjpeg-progs is also provided by the turbo variant of same of
>> package. With libjpeg-turbo replacing libjpeg8, I cannot see the issue?
>
> Hello Niels,
>
> The libjpeg-turbo package provides an older version of theses tools which have
> less capabilities than what is in wheezy already (and this is even more true
> when compared with the jessie version). In particular the libjpeg-turbo version
> is unable to process files that could be readn and generated by the wheezy
> version.
>
Hi,
Could you list the features that the turbo-variant is missing, which are
present in the current version of libjpeg-progs from Wheezy? Are there
any lacking features beyond the "SmartScale" feature?
> Accordingly wheezy systems with libjpeg-progs will not have libjpeg-progs
> replaced by libjpeg-turbo-progs automatically when upgrading to jessie.
>
I see. This is certainly an issue.
> Furthermore, removing this package would be inconsistent with the decision
> of the CTTE which called only for the removal of the Provides: libjpeg-dev
> by libjpeg8, but not of the actual libjpeg8-dev package, and neither for
> the wholesale removal of libjpeg8.
>
> Cheers,
>
I am afraid I do not see how removing libjpeg9 from testing is
inconsistent with the tech-ctte decision. The very first item of their
resolution text states that:
1. [...] The release team does not want to have more than one libjpeg
implementation.
Then further down, they follow up with:
10. The Technical Committee resolves that libjpeg-turbo should
become the libjpeg implementation in Debian, [...]
Quote from [1].
Thanks,
~Niels
[1] https://lists.debian.org/debian-devel-announce/2014/08/msg00000.html
Reply to: