Bug#734328: Bug#726248: Bug#734328: kfreebsd-kernel-headers: Don't ship sys/sdt.h here

2014-01-19 Thread Robert Millan
tags 726248 pending
thanks

On 19/01/2014 08:53, Samuel Bronson wrote:
 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.

OK. Makes sense, thanks for the explanation.

-- 
Robert Millan


-- 
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/52dc7043.6030...@debian.org



Bug#734328: Bug#726248: Bug#734328: kfreebsd-kernel-headers: Don't ship sys/sdt.h here

2014-01-18 Thread Samuel Bronson
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