Hi
On Friday 25 April 2014, you wrote:
> On 25.04.2014 01:39, Julien Cristau wrote:
> > On Thu, Apr 24, 2014 at 23:51:34 +0800, Rolf Leggewie wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian....@packages.debian.org
> >> Usertags: rm
[...]
[ Disclaimer, I cannot speak for the release team. Please CC me, if
you want to respond to this mail ]
> Hm, I'm really at a loss about this one myself. I've been the
> maintainer for isdnutils for a number of years and my main focus has
> always been to get rid of the many, many hacks in isdnutils that were
> somehow working, but unhealthy and unmaintainable, especially all the
> hand-crafted scripting. There's been an NMU that I do not approve of
> and I consider hackish. It works around a kernel problem and thus is
> out of place in isdnutils. I do not want to bless that NMU with an
> upload of mine. At the same time, reversing that NMU would create a
> backlash and wouldn't be the right thing, either, I think. Essentially,
> I am unable to upload to unstable. I've seen experimental as the only
> venue left for me. I was unaware it would not be sufficient.
Ignoring unstable (and therefore testing) isn't a modus operandi that
works long term. Actually removing the package from testing is a larger
disruption to the user (as it won't be part of the jessie release that
way, unless you fix the problem and let a newer version migrate into
testing again) than either acknowledging the changes or reverting them.
> I carved out libcapi20-3 from the isdnutils package for greater
> modularity and I'd like it to migrate to testing. In 2005, a versioned
> dependency on libcapi20-3 was introduced in the pppdcapiplugin and
> capiutils "Depends: libcapi20-3 (= ${binary:Version})". I've contacted
> doko who apparently uploaded that change to see if that is really
> necessary, I believe it's not and can be relaxed to an unversioned
> dependency.
>
> The same reason that prevents the migration is now obviously preventing
> the removal of the testing package. Two things need to be done, I guess
> in isdnutils in testing if the binary package cannot be temporarily
> removed without too much collateral damage.
Consider this from a different angle, if you want to maintain
isdnutils, the package needs to work - including on systems using udev
(which are almost 100% of all systems today, at least the systems using
Debian's own kernel packages). In order to work, the device nodes for
ISDN4LINUX/ hisax need to be created one way or another, ideally via
the kernel (but the kernel has already deprecated hisax and happily
ignores this subsystem in favour of misdn, which doesn't have this
problem), while a (non-trivial) patch would probably accepted upstream,
I don't see that anyone has invested the time for doing this. Therefore
the remaining option would be make isdnutils (or another package it
depends on) to create the necessary devive nodes in its initscripts,
as it has been done in the wheezy/ testing/ unstable package.
As kind of a compromise, did you consider to contain the nasty bits and
pieces (device node messing) in their own dedicated init script? That
way ISDN4LINUX would continue to work, until the problem is solved at
the proper level (which it probably will never be).
> 1) stop building the libcapi20-3 binary
> 2) relax the versioned run-time dependency above to an unversioned one
>
> For the package to successfully migrate from unstable to testing a few
> RC-bugs would need to be addressed as well, though (#745624, #725000,
> #710359). I'm willing to do that work, but like I stated, I feel
> precluded from doing it in unstable. I'm hoping for a suggestion on how
> to move this forward in the best interest of everyone involved. How do
> we get out of this situation?
Talking about a potential removal of isdnutils, be it temporarily from
testing or alltogether:
- drdsl is in non-free - therefore it doesn't matter here. Do the
non-free kernel modules AVM has stopped maintaining in 2005 even
compile these days?
- isdnactivecards is in contrib, so basically the same applies as for
drdsl, likewise the supported active ISDN cards aren't that common
(nor still available on the market) anymore.
- ibod matters a bit more, but there'd be alternatives for misdn.
Did you consider to deprecate (and subsequently remove) isdnutils in
favour of the newer misdn subsystem? While not all devices supported
by hisax have corresponding misdn coverage, most of the ones that
remain useful today should be supported and from what I can read, misdn
should support equivalent functionality (and more, asterisk et al) to
hisax (or the ancient non-free capi drivers) for the devices it
supports.
[ While I still have ISDN and several ISDN cards supported by both
hisax and misdn (or even the ancient non-free CAPI drivers back in
those days), I haven't actually used it for non-phone uses in almost
a decade, so take my advice with a grain of salt. ]
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
