Hi, as 726...@bugs.debian.org only goes to the maintainer I'm resending this with a wider Cc list.
-Timo -----Original Message----- From: Mark Wielaard <m...@redhat.com> Sent: Fri, 18 Oct 2013 10:50:15 +0200 To: 726...@bugs.debian.org Subject: Bug#726248: sdt.h conflict with kfreebsd-kernel-headers and systemtap-sdt-dev On Fri, 2013-10-18 at 10:39 +0200, Robert Millan wrote: > I'm sorry, but I just can't see how this could fly. If systemtap-sdt-dev > is not meant unusable on non-Linux architectures, and you provide it in > them, you have to be able to deal with the fact that this package will > fail on them. It is certainly meant to be usable for software that wants to use SDT probes (like glibc in this example) and software that wants to read/inspect the SDT probes embedded in other software (like gdb in this example). > I don't think it does any serious harm to kfreebsd-* ports that > systemtap-sdt-dev is available despite that it is unusable. However if > this is inconvenient for other reasons, we really can't help you about > it. This package shouldn't be provided for kfreebsd-* in first place. Does kfreebsd use gcc/glibc/gdb/etc? Then it should be available for it so that software that uses STAP/DTRACE_PROBE SDT macros can be build on it. The confusion might be that it has systemtap- in the package name (that is because it originated through the systemtap project). And systemtap at the moment is indeed linux kernel specific. But the sys/sdt.h header (and dtrace compatible python script) provided by the package are not tied to systemtap at all. Other tools like perf and gdb provide other consumers of the SDT probes. -- 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/8438nyfi35....@sauna.l.org
