Jakub Wilk jw...@debian.org wrote:
* Mathieu Malaterre ma...@debian.org, 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
* Mathieu Malaterre ma...@debian.org, 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
[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
On Mon, Mar 24, 2014 at 4:38 AM, Mathieu Malaterre ma...@debian.org 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
On Mon, Mar 24, 2014 at 5:44 PM, Cameron Norman
camerontnor...@gmail.com wrote:
On Mon, Mar 24, 2014 at 4:38 AM, Mathieu Malaterre ma...@debian.org 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
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,
6 matches
Mail list logo