severity 492145 important
thanks
Ian Jackson wrote:
> 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 don't think that's ok, though adns wouldn't migrate to testing without
a fixed sauce anyway...
> 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'.
Ideally we would indeed fix all bugs and not only RC bugs.
> 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.
I don't intend to finger-point anyone, I just disagree that it's an RC
bug and you're just challenging my authority...
> 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.
I agree on that, though that still doesn't mean the bug should be RC.
> 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.
Right, though RC is only for things that are required...
> 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.
A conflicting file is an RC bug against both packages.
> 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.
Many library transitions just do make lots of packages instantly
uninstallable... unless there is a clear reason why the old library
should be kept around, we don't file an RC bug against the library
package, but just update all broken packages...
Changing the severity of adns' bug to important to indicate that it's
not RC, but everyone wants it to be fixed.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
