Bug#734328: Bug#726248: Bug#734328: kfreebsd-kernel-headers: Don't ship <sys/sdt.h> here
Robert Millan <rmh@debian.org> writes:
> What's wrong with Replaces: ? I proposed this in my last mail, but it
> went unanswered:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#105
>
> I really don't see why you want us to remove legacy functionality from
> k-k-h. As far as I can see its presence doesn't stop you from providing
> an alternative and making other packages Build-Depend on it.
Hmm, I must have thought this was covered well enough in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#110
But I guess that left out the detail that Replaces is supposed to be
accompanied by Breaks (or Conflicts?), which is iirc due to the
unpleasent consequences that occur if you remove the replacing package
before the replaced package: the files are just gone. So, if you want
to continue to make those files available, it's best if you split them
off into their own, non-build-essential package, which systemtap-sdt-dev
could safely conflict with, but dtrace could still explicitly use.
And having a -dev package that conflicts with something in
build-essential is a non-starter: besides the impracticality of
replacing the *rest* of the kFreeBSD headers, the buildds are NOT smart
enough to allow installing a package conflicting with/providing one in
build-essential. (I belive this is deliberate.)
> As for the dtrace userland, we don't have it yet, but we're much closer.
> There's a ctfutils package, and latest versions of the kernel are built
> with CTF debug information and dtrace support now.
>
> I think that eventually we can have both implementations of SDT probes.
> Systemtap obviously has better integration with the GNU toolchain but
> DTrace will most likely have better kernel integration for us. I think
> there's room for both options and I think it's great to have this choice.
> So why remove the BSD version of <sys/sdt.h>? Better to provide users
> with two great tools than just one, don't you think?
Yes, that would be nicest, though I'd hope that they could eventually
agree to use (something like) Systemtap's NOP-ful representation[1] for
probe points rather than having their own incompatible ABIs for
overlapping APIs like they do now.
[1]: https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Reply to: