Package: developers-reference Version: 3.3.6 Severity: wishlist The current procedure for creating dummy/transition packages for phasing out a package in preference for a different one is entirely ad hoc. This creates an unnecessary burden on developers in a number of ways. Best practices and/or automation would help.
First, I naively started building my dummy/transition package for xpilot by incrementing the Debian version#. This is wrong because the original source should be removed from the archive, as it is no longer useful. The upstream version# must be incremented for that to happen. Second, I stumbled over what to call the new version, as upstream didn't really produce a new version#. Thus, I must come up with a version# that is greater than upstream's current version#, yet less than a subsequent release by upstream, should they ever decide to finally release a new version, thereby introducing the possibility of re-introducing the package into Debian. This suggests a .# suffix to the upstream version# is the best way to make the increment. Depending on the upstream version#, some .# suffixes are better than others. Third, I stumbled over the description: there are many and varied descriptions of dummy packages in Debian right now, so I have many templates to choose from. This adds an extra burden on the translators, who must translate each variant of the text. I don't see the purpose of such variation, given that all of these packages have the same purpose. It would be better if there were a flag on a dummy package that indicates it is a dummy, and which automatically supplies these texts, rather than to have all of this unnecessary duplication of descriptions in our archive. But in the absence of such a flag, a best practices document with a recommended dummy package description text in it would help. I did find one section that dealt with an isolated transition/dummy package topic, 6.7.7. Make transition packages deborphan compliant. Please consider expanding this section to cover transition package best practices in general, providing best practice solutions to the problems I have sketched out above, adding to those as needed. Thanks, Ben Armstrong <synrg at debian dot org> -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy 3.6.2.1 Debian Policy Manual and related d -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
