Jakub Wilk wrote:
> * Mathieu Malaterre , 2014-03-24, 12:38:
>> I am preparing to upload openjpeg 2.0. This is a major API (yes API)
>> change from previous openjpeg 1.x.
>
> None of these openjpeg versions seem to use versioned symbols. If you
> want to have both in the archive at the same, then
* Mathieu Malaterre , 2014-03-24, 12:38:
I am preparing to upload openjpeg 2.0. This is a major API (yes API)
change from previous openjpeg 1.x.
None of these openjpeg versions seem to use versioned symbols. If you
want to have both in the archive at the same, then both should use them.
--
On Mon, Mar 24, 2014 at 17:57:21 +0100, Mathieu Malaterre wrote:
> Unless I missed your point: It did work somewhat ok for tiff3/tiff4
> source packages AFAIK. No-one depends on source packages directly,
> right ?
>
Please don't take tiff as an example. No API change was involved there.
Cheers,
On Mon, Mar 24, 2014 at 5:44 PM, Cameron Norman
wrote:
> On Mon, Mar 24, 2014 at 4:38 AM, Mathieu Malaterre wrote:
>>
>>
>> Which way should I go:
>>
>> 1. Upload a src:openjpeg1 which will contains the legacy openjpeg 1.x
>> branch and src:openjepg will get openjpeg 2.x or
>> 2. Upload a new s
On Mon, Mar 24, 2014 at 4:38 AM, Mathieu Malaterre wrote:
>
> Which way should I go:
>
> 1. Upload a src:openjpeg1 which will contains the legacy openjpeg 1.x
> branch and src:openjepg will get openjpeg 2.x or
> 2. Upload a new src:openjpeg2 with the goal to get rid of src:openjpeg
> in a coupl
[Couldn't get any info from debian-mentors, so reposting to debian-devel]
Hi,
I am preparing to upload openjpeg 2.0. This is a major API (yes API)
change from previous openjpeg 1.x. I am thinking of doing something
similar to gtk+1.2 and gtk+2.0 packages. Basically we will have two source
packa
6 matches
Mail list logo
