[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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.

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           Debian Policy Manual and related d

-- no debconf information

Reply to: