Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Package renaming, and transitional dependencies (http://www.linux-archive.org/debian-development/130563-package-renaming-transitional-dependencies.html)

Ian Jackson 07-24-2008 12:31 AM

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.)
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.)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


All times are GMT. The time now is 08:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.