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

[Robert Millan <rmh@debian.org>]

Hi Samuel,

On 06/01/2014 00:59, Samuel Bronson wrote:
> Given the facts:
> 
>   - nobody has ported the dtrace userspace to [e]glibc yet
>   
>   - there *are* packages that could benefit from systemtap's version of
>     <sys/sdt.h>; in particular, GDB can use such probes, and has
>     particular support for ones in [e]glibc and libgcc (see
>     <http://bugs.debian.org/726248>)
> 
>   - this package and systemtap-sdt-dev can't *both* install <sys/sdt.h>
> 
> it doesn't seem particularly useful for you to ship the
> dtrace-compatible <sys/sdt.h> in this package.
> 
> <http://bugs.debian.org/726248> has a lot of discussion about this.
> 
> (It might *possibly* be useful for people running Debian in a chroot,
> but on the other hand wouldn't they need a copy of dtrace in there to be
> able to include all the necessary metadata in their binaries anyway?  If
> so, it seems unlikely to be much more work for them to install the
> dtrace-compatible <sys/sdt.h> at the same time.  Or, if that worries
> you, you could split it into its own package.)

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.

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?

-- 
Robert Millan