Robert Millan <r...@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! -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3dwtnk6....@naesten.dyndns.org
