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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
