severity 490764 serious
severity 492145 serious
thanks

Firstly, process:

I'm adjusting these severities to preserve the status quo, which is
that the new adns-tools doesn't propagate and introduce what I regard
as new RC bugs into testing.  I hope that's OK.

I would like ideally to improve both packages.  So with the
adns maintainer's and release managers' permission I would like to
push a new version of adns which also `Provides: libadns1-bin'.

If I receive affirmative answers I will make a suitable uploads
including an adns NMU straight away and then hopefully we can avoid
having this turn into some hideous finger-pointing exercise.


Secondly, the hideous finger-pointing exercise:

Luk Claes writes ("Bug#490764: adns-tools should provide compatibility"):
> That's not RC at all as only a few packages are involved and easy
> backporting is not required. It would be nice to do have the Provides
> anyway, though that's a minor bug IMHO.

Evidently you have read my message on this subject on debian-devel but
I'm afraid that my point doesn't seem to have been clear enough.

It is not enough to say that `only a few packages [in Debian]' are
broken, because our users are not only users directly of Debian.  We
are trying to make Free Software, which is software which our users
may modify and redistribute.  That ability has to be practical, not
just theoretical, and where it costs us little effort we should take
steps to do so.

To say that `easy backporting is not required' is completely missing
the point.  Easy back- and forward-porting is _desirable_.  There is
no reason to break it in this case.

> A package that is not installable has an RC bug anyway whether it gets
> fixed in the package itself or not...

If the dpkg maintainers were to introduce a new version of dpkg which
contained a file /bin/ed, that would make the `ed' package
uninstallable.  So by your logic, that would mean that the ed package
would have an RC bug.

Obviously this is absurd.  When there is an uninstallable package it
means that _the distribution_ has a release-critical bug.  What we
mean by saying that the bug is `in' a particular package, is that we
think that it is that package which should change.

It seems obviously unreasonable to me for a package to make other
packages uninstallable for no good reason, and then for us to just
declare them all RC-buggy!  Surely it is the new version which breaks
things which has the RC bug.

Ian.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to