Package: argyll
Version: 1.3.0-3

The packages argyll and libicc2 are both taking their source code from the upstream source tarball of Argyll. Having two (or more) different packages based on the same source code tarball one will easily get into a maintenance nightmare. If a security vulnerability shows up in the upstream code, all packages based on it need their upstream tarball be updated and rebuilt. One can easily forget one package and so the vulnerability stays in the forgotten package.

I am introducing Color Management in Ubuntu and therefore I have updated the Argyll package to version 1.3.3 and also created a merged package (but not uploaded to Ubuntu). You can download it here:

http://www.openprinting.org/download/tmp/argyll_1.3.3.orig.tar.gz
http://www.openprinting.org/download/tmp/argyll_1.3.3-0ubuntu2.dsc
http://www.openprinting.org/download/tmp/argyll_1.3.3-0ubuntu2.debian.tar.gz

Problem is that the version number used for libicc is the API/ABI version number 2.12 which is much higher than the 1.3.3 of the upstream tarball. Ho should I proceed to make the resulting package being well accepted by Debian? Should I introduce an epoch? Or can a binary package have another version number than its source package?

The mentioned package uses an epoch, but please tell me how to do it correctly.

the merged package builds Argyll using the upstream Jam architecture, this makes maintenance much easier than with a packager-supplied autoconf/automake environment. Only libicc is built in a separate directory using the very simple autoconf/automake files from the former libicc2 package. This is done because the Jam environment has no functionality to create shared libraries.

The package is a merger of Ubuntu packages, therefore it has Ubuntu release numbers, change them if you want to use this package in Debian.

   Till



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to