One source package, multiple binary packages with different version numbers - courier
Hi,
I am an early user of the courier packages by Stefan Hornburg who have
been uploaded to the archive a week ago. I am using these packages a
little bit longer, backported them to my potato servers and have
contributed some stuff. However, there is one thing that makes the
package unique and makes it harder to do a proper backport.
Courier is an MTA, a POP 3 server, an IMAP server and much more. The
only component that has been packaged for Debian previously is the
IMAP server which has a 1.3 version number. Stefan adopted
courier-imap from the previous maintainer.
Courier upstream comes as a single tarball, currently at 0.32,
including courier-mta 0.32, courier-pop 0.32, and courier-imap 1.3.4.
To provide a smooth upgrade path for users of the older courier-imap
package, Stefan hacked the debian/rules file to pull the version
number for the courier-imap deb not from debian/changelog, but from a
hard coded version number in the rule file. This breaks my backports
since I routinely modify the backports' version numbers. For example,
when I backport foo_1.2-3, I make my backport foo_1.2-3mycompany3 to
make sure that a new Debian version will override mine, even if I had
to do multiple releases of my backport (probably giving version
numbers like foo_1.2.3mycompany5).
Is it policy compliant to built binary packages that have a version
number that doesn't fit the version number of the source package? What
would experienced maintainers do in this situation?
The only solution I could think of would be using epochs, but that's
ugly, too.
Any ideas how to solve this?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Reply to: