Package renaming, and transitional dependencies
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.)
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'
- 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
(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