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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
