Bug#323066: Best practices for dummy/transition packages
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
Reply to: