Description of problem: Perl introduces header dependency to sys/sdt.h, but no RPM requirement to systemtap-sdt-devel. [...] gcc -c -I../src -I. -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"2.22\" -DXS_VERSION=\"2.22\" -fPIC "-I/usr/lib64/perl5/CORE" -DSPEEDY_PROGNAME=\"speedy_backend\" -DSPEEDY_VERSION=\"2.22\" -DSPEEDY_BACKEND speedy_backend_main.c In file included from /usr/lib64/perl5/CORE/mydtrace.h:14:0, from /usr/lib64/perl5/CORE/cop.h:138, from /usr/lib64/perl5/CORE/perl.h:3428, from ../src/speedy_inc_perl.h:25, from speedy.h:1, from speedy_backend_main.c:24: /usr/lib64/perl5/CORE/perldtrace.h:6:21: fatal error: sys/sdt.h: No such file or directory compilation terminated. [...] See: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/perl-CGI-SpeedyCGI-2.22-8.fc14.src.rpm/result/build.log Version-Release number of selected component (if applicable): perl-devel.x86_64 4:5.12.2-144.fc15 How reproducible: Everytime, see above. Actual results: Perl introduces header dependency to sys/sdt.h, but no RPM requirement Expected results: Add a "Requires: systemtap-sdt-devel" to the correct perl subpackage, please.
The requirement should be in perl interpreter, but adding systemtap as requirement means dragging into minimal install also systemtap. That's not right. The idea was that if someone use systemtap, then he knows he needs install it.
I've also run into this when building perl-autobox. It doesn't appear to be a runtime dependency, merely compile time for anything that ends up including perldtrace.h (which in turn includes sys/sdt.h). Since it's the perl headers that want sys/sdt.h, I would think it's appropriate for perl-devel to Require: systemtap-sdt-devel, rather than force any affected module to BuildRequire it. Note that f14 is affected too, not just rawhide.
Marcela, did you misget me somehow? After looking to the packages myself, I would say: "BuildRequires: systemtap-sdt-devel" needs to be added to perl-devel package. That - or remove systemtap from perl again, if you do not want it. But as long as perl has somehow a build-time requirement in *.h, from my point of view, there needs to be a build-time RPM requirement which is "BuildRequires: systemtap-sdt-devel". As this header file is in the perl-devel package, the BuildRequires belongs to this subpackage. Does this make sense to you?
(In reply to comment #3) > Marcela, did you misget me somehow? After looking to the packages myself, > I would say: "BuildRequires: systemtap-sdt-devel" needs to be added to > perl-devel package. That - or remove systemtap from perl again, if you do > not want it. But as long as perl has somehow a build-time requirement in > *.h, from my point of view, there needs to be a build-time RPM requirement > which is "BuildRequires: systemtap-sdt-devel". As this header file is in > the perl-devel package, the BuildRequires belongs to this subpackage. Does > this make sense to you? Except that all of those BuildRequires should be simple Requires. systemtap-sdt-devel is a *run-time* requirement of perl-devel, and consequently gets pulled in at build-time when compiling modules.
(In reply to comment #3) > remove systemtap from perl again, if you do > not want it. Let me ask differently: What was the reason to add systemtap to perl? Unless there is a _very_ compelling reason for having it, I'd rather remove it.
(In reply to comment #2) > I've also run into this when building perl-autobox. It doesn't appear to be a > runtime dependency, merely compile time for anything that ends up including > perldtrace.h (which in turn includes sys/sdt.h). > > Since it's the perl headers that want sys/sdt.h, I would think it's appropriate > for perl-devel to Require: systemtap-sdt-devel, rather than force any affected > module to BuildRequire it. > > Note that f14 is affected too, not just rawhide. Ok, that's make it clear.
(In reply to comment #5) > (In reply to comment #3) > > remove systemtap from perl again, if you do > > not want it. > Let me ask differently: What was the reason to add systemtap to perl? > > Unless there is a _very_ compelling reason for having it, I'd rather remove it. Systemtap/dtrace support in Perl was a feature of Perl5.12, so I built it with this enablement.
Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, not BuildRequires, as a BuildRequires doesn't make for this bug report.
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #3) > > > remove systemtap from perl again, if you do > > > not want it. > > Let me ask differently: What was the reason to add systemtap to perl? > > > > Unless there is a _very_ compelling reason for having it, I'd rather remove it. > > Systemtap/dtrace support in Perl was a feature of Perl5.12, so I built it with > this enablement. OK, what is it used for? Which benefits does it offer to the user? So far, I don't even have systemtap installed ;) (In reply to comment #8) > Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, > not BuildRequires, as a BuildRequires doesn't make for this bug report. Certainly, but ... I don't want systemtap installed on my system. Also there is a packaging issue: systemtap-sdt-devel pulls in python, i.e. R: system-tap-devel would tie together perl and python. IMO, this means, systemtap-sdt-devel needs to be split into python and non-python parts, otherwise long term chaos is assured.
> (In reply to comment #8) > > Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, > > not BuildRequires, as a BuildRequires doesn't make for this bug report. > > Certainly, but ... I don't want systemtap installed on my system. > Welcome in binary distribution. Use Gentoo or SourceMage ;)
(In reply to comment #10) > > (In reply to comment #8) > > > Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, > > > not BuildRequires, as a BuildRequires doesn't make for this bug report. > > > > Certainly, but ... I don't want systemtap installed on my system. > > > Welcome in binary distribution. Use Gentoo or SourceMage ;) ... or LFS :)
> (In reply to comment #10) > > (In reply to comment #8) > > > Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, > > > not BuildRequires, as a BuildRequires doesn't make for this bug report. > > > > Certainly, but ... I don't want systemtap installed on my system. > > > Welcome in binary distribution. Use Gentoo or SourceMage ;) > (In reply to comment #10) > > > (In reply to comment #8) > > > > Eh...sorry, I of course mean "Requires: systemtap-sdt-devel" in perl-devel, > > > > not BuildRequires, as a BuildRequires doesn't make for this bug report. > > > > > > Certainly, but ... I don't want systemtap installed on my system. > > > > > Welcome in binary distribution. Use Gentoo or SourceMage ;) > > ... or LFS :) Thank you both for providing another example of Red Hat employees' understanding of collaboration - This is way beyond of behaving "excellent" and fair!
In binary distribution all users get the same packages. From point of view of end-user (yeah, RPM users are proud they do not need to compile) you can disable the feature, you can move the feature to sub-package, or you can compile sources twice providing two binary packages with and without the feature. However from point of view of developer, you need to compile your package with the same set of features as provides the discussed package (perl). Therefore perl-devel needs to depend on systemtap if perl is compiled against it. So the only question is weather Fedora is to enable systemtap or not. You do not use it. I do not use it. However there can be users who use it. I think perl bug is not proper place where to discuss it. It requires wider scope to deal with it, like a fedora-devel list.
> OK, what is it used for? Which benefits does it offer to the user? Better run-time diagnostics, profiling. > Also there is a packaging issue: systemtap-sdt-devel pulls in python, i.e. > R: system-tap-devel would tie together perl and python. > IMO, this means, systemtap-sdt-devel needs to be split into python and > non-python parts, otherwise long term chaos is assured. Long term, the /usr/bin/dtrace script could be rewritten in non-python, to avoid that chaos, should it become impending. (In practice, few fedora machines exist without python already installed.)
Sum up: - to build some Perl modules systemtap dependency is needed in perl-devel - problem is adding python as dependency into Perl I'd like to close it with commit 3e4ca7b3a71364205bd405cadad26153ec3c7b1e
Ok, now should be fixed dependent packages like perl-autobox, ...