Package renaming, and transitional dependencies

[Ian Jackson <ian@davenant.greenend.org.uk>]

Recently, this happened:

 1. A .deb in which I have an interest, but of which I am
    not the maintainer, had its binary package name changed.

So far so good.  (In fact I actually approve of the change.)
However, then:

 2. The maintainer of this package discovered that its testing
    propagation was or would be blocked by the fact that it would
    render a bunch of its rdepends uninstallable.

 3. So the maintainer and others filed a bunch of bugs at
    release-critical severity against the various rdepends.

 4. Due to my own slackness, I did not reply to these bugs
    until today, about a week later.

 5. One of the rdepends was NMUd with a changed Depends
    to make this `release critical bug' disappear.

It seems to me that:

 * When a binary package name is changed, transitional arrangements
   for cross-version compatibility with previously released versions
   of the binary package should normally be made, unless there is a
   good reason not to do so.

   Providing backwards compabitility features:
    - makes the maintenance of our distro easier by decoupling
      different packages so that we are much less on each others'
      critical paths
    - makes the distro better for our users by making partial and
      incremental upgrades easier and more reliable
    - makes the lives of backporters and forward-porters easier (and
      we are all sometimes a back- or forward-porter, surely?)
    - avoids unnecessarily breaking the systems of people who have
      exercised their freedom to modify Debian for example by creating
      local packages or whole derivative distributions
    - can avoid introducing breakages which are not detected by the
      testing propagation scripts and our other QA processes

   Obviously backwards compatibility can come with a cost and
   sometimes it is right not to pay that cost but I can't see that
   being at all the situation in this case, which is almost a poster
   child for `free' backwards compatibility.

 * In this particular case a simple `Provides' would have done the job
   admirably.  (The new binary already has Conflicts/Replaces.)

 * Failure to provide a transitional arrangement in your package does
   not automatically entitle you to declare a bunch of other packages
   RC-buggy for not keeping up.

 * I should read and reply to my email more promptly.

Am I wrong ?  At least one person close to the release team appeared
to agree with the maintainer's decision to declare this a bug in the
dependent packages.

Ian.

(References: the other package is adns, whose product libadns1-bin was
 renamed to adns-tools; the package that was NMUd is the rather stale
 autopkgtest and a few others have had bugs filed.  I'm upstream for
 adns but this is not relevant.  I don't want to point the finger here
 as I don't like to make these kind of complaints excessively
 personal.)