Spot went through this bug that has been around forever, and wrote up some review comments. I cleaned up some of the low hanging fruit, but there's still a few that I'm uncertain on. input welcomed.
kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so
(I don't begin to claim that I understand what's happening here, but I suspect that these vdso files server a specific purpose and that these warnings do not apply to them.)
I'm going to assume this is to be expected, as they aren't 'real' libraries. Roland ?
kernel.x86_64: W: no-documentation
(At a minimum, COPYING should be present as %doc with the GPLv2 terms.)
I'm not sure this makes sense when we have a kernel-doc package. Though I note we don't have COPYING in there either.
kernel.x86_64: W: dangling-relative-symlink /lib/modules/2.6.36-1.fc15.x86_64/build ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
(It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in kernel, but the symlink it points to is in kernel-devel. Is there a reason that the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?)
We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed.
kernel.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf
(Should this be marked as %config(noreplace)?)
it's versioned, so no ? I think ?
kernel-devel.x86_64: W: no-documentation (There are documentation files included in kernel-devel, they are not marked as %doc though. Recognizing that the kernel-devel file list is autogenerated, I can't see a good way to accomplish this file marking, so I propose that this is safe to ignore.)
ack.
kernel-devel.x86_64: E: zero-length /usr/src/kernels/2.6.36-1.fc15.x86_64/include/config/fb/via.h [ ... repeated for several hundred empty kernel .h files ... ]
(I assume that all of these zero length header files are kernel header files which are not intended to be exposed/exported to userspace. Perhaps it makes sense to iterate through the buildroot at the end of install and delete all of the zero length header files? Might speed up the -devel transaction.)
Something in the tree could be #include'ing them, but I don't see anything from a quick grep. Not sure about this. (They're autogenerated, and their content varies depending on CONFIG options being set).
kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/rt-tester/rt-tester.py 0644L /usr/bin/python kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/headers_install.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-x86_32-has-stack-protector.sh 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gfp-translate 0644L /bin/bash kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/kconfig/lxdialog/check-lxdialog.sh 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/export_report.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/mksysmap 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/package/builddeb 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gen_initramfs_list.sh 0644L /bin/bash kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/bootgraph.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/tracing/draw_functrace.py 0644L /usr/bin/python kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/headers_check.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/selinux/install_policy.sh 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-version.sh 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/profile2linkerlist.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/kconfig/streamline_config.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/markup_oops.pl 0644L /usr/bin/perl kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/mkmakefile 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/package/buildtar 0644L /bin/sh kernel-devel.x86_64: E: non-executable-script /usr/src/kernels/2.6.36-1.fc15.x86_64/scripts/gcc-x86_64-has-stack-protector.sh 0644L /bin/sh
(These script files are being packaged, but probably set to chmod -x to prevent kernel-devel from picking up dependencies. This list of files should be reviewed to see whether they should remain in kernel-devel or be deleted from the buildroot at the end of %install. If any of these files are useful and are kept in kernel-devel, they should be set executable so proper dependencies are found for these scripts by RPM.)
I think we can probably just kill all of these.
everything else on spots list I committed already.
Dave
Dave Jones (davej@redhat.com) said:
kernel.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf
(Should this be marked as %config(noreplace)?)
it's versioned, so no ? I think ?
I would assume that ld.so.conf.d files aren't really config files in the normal sense. Certainly, they're not intended to actually be user-editable.
That being said:
$ cat /etc/ld.so.conf.d/kernel-2.6.35.6-45.fc14.x86_64.conf # Placeholder file, no vDSO hwcap entries used in this kernel.
If that's the case, why package it at all?
Bill
On Tue, Oct 26, 2010 at 02:18:52PM -0400, Bill Nottingham wrote:
Dave Jones (davej@redhat.com) said:
kernel.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf
(Should this be marked as %config(noreplace)?)
it's versioned, so no ? I think ?
I would assume that ld.so.conf.d files aren't really config files in the normal sense. Certainly, they're not intended to actually be user-editable.
That being said:
$ cat /etc/ld.so.conf.d/kernel-2.6.35.6-45.fc14.x86_64.conf # Placeholder file, no vDSO hwcap entries used in this kernel.
If that's the case, why package it at all?
hah. good point. I think this might be a leftover from when we had Xen. Roland might remember more.
Dave
$ cat /etc/ld.so.conf.d/kernel-2.6.35.6-45.fc14.x86_64.conf # Placeholder file, no vDSO hwcap entries used in this kernel.
If that's the case, why package it at all?
There's no need for it. We just don't have a way (with .spec magic I know, anyway) to decide at the right time whether we need one or not. The kernel's 'make vdso_install' target either does or doesn't make one. Except AFAIK none ever does at this point, apparently because the Xen support it was there for fell out. There was a time when we thought that the powerpc and/or s390 vDSOs might use the same mechanism too, but apparently they never did try to do that.
Thanks, Roland
kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so kernel.x86_64: E: shared-lib-without-dependency-information /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so kernel.x86_64: E: missing-PT_GNU_STACK-section /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so
(I don't begin to claim that I understand what's happening here, but I suspect that these vdso files server a specific purpose and that these warnings do not apply to them.)
I'm going to assume this is to be expected, as they aren't 'real' libraries. Roland ?
Yes, they would be meaningless if they were there. It would be ~harmless (just sizeof(Elf{32,64}_Phdr bloat in the vdso image, fine as long as it doesn't push it over another page) to add it to the vdso linker script, but it would have no meaning whatsoever.
kernel.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf
(Should this be marked as %config(noreplace)?)
it's versioned, so no ? I think ?
I don't really grok with %config(noreplace) means. The file is indeed versioned. It only lives in /etc because /etc/ld.so.conf.d is where you put things to get them seen by ldconfig. It could as well be a symlink (of that same name) to a file living somewhere else (in /lib/modules/V/vdso/ I guess), if rpm rules like that better.
kernel-devel.x86_64: E: zero-length /usr/src/kernels/2.6.36-1.fc15.x86_64/include/config/fb/via.h [ ... repeated for several hundred empty kernel .h files ... ]
(I assume that all of these zero length header files are kernel header files which are not intended to be exposed/exported to userspace. Perhaps it makes sense to iterate through the buildroot at the end of install and delete all of the zero length header files? Might speed up the -devel transaction.)
Something in the tree could be #include'ing them, but I don't see anything from a quick grep. Not sure about this. (They're autogenerated, and their content varies depending on CONFIG options being set).
They exist to embody the .config state. I think you need all that stuff as it is to build modules correctly.
I think we can probably just kill all of these.
As long as you can definitely build a kernel module, including all the kinds of modules systemtap ever wants to build, then sure.
Thanks, Roland
On Tue, Oct 26, 2010 at 02:10:23PM -0400, Dave Jones wrote:
kernel.x86_64: W: dangling-relative-symlink /lib/modules/2.6.36-1.fc15.x86_64/build ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
(It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in kernel, but the symlink it points to is in kernel-devel. Is there a reason that the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?)
We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed.
I think the problem was the -devel package could be installed without a kernel package behind it making it awkward to install a symlink. Even if you just dropped the symlink on the floor, installing the kernel later would never re-create the symlink leaving things broken.
IIRC, the dangling symlink was the lesser of two evils.
Not that I care either way.
Cheers, Don
On 10/26/2010 03:09 PM, Don Zickus wrote:
On Tue, Oct 26, 2010 at 02:10:23PM -0400, Dave Jones wrote:
kernel.x86_64: W: dangling-relative-symlink /lib/modules/2.6.36-1.fc15.x86_64/build ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
(It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in kernel, but the symlink it points to is in kernel-devel. Is there a reason that the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?)
We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed.
I think the problem was the -devel package could be installed without a kernel package behind it making it awkward to install a symlink. Even if you just dropped the symlink on the floor, installing the kernel later would never re-create the symlink leaving things broken.
IIRC, the dangling symlink was the lesser of two evils.
Well, all the real "meat" is in kernel-devel, except for the /lib/modules/%{version}-%{release}.%{_arch}/build symlink which is in kernel. My point was that it seems to make sense to just put that symlink in kernel-devel as well, that way, you either have kernel-devel installed (and have all the files and the symlink) or you don't.
As is, if you just have kernel installed (and not kernel-devel), you currently have a dangling symlink.
~spot
Well, all the real "meat" is in kernel-devel, except for the /lib/modules/%{version}-%{release}.%{_arch}/build symlink which is in kernel. My point was that it seems to make sense to just put that symlink in kernel-devel as well, that way, you either have kernel-devel installed (and have all the files and the symlink) or you don't.
As is, if you just have kernel installed (and not kernel-devel), you currently have a dangling symlink.
Indeed that seems pointless. My only guess about its historic origin is that it's somehow better for the kernel package to own the /lib/modules/%{version}-%{release}.%{_arch} directory rather than the kernel-devel package supplying/owning that directory also just so it can own the symlink. Cue ominous music for rpm black magic.
On Wed, Oct 27, 2010 at 10:02:10AM -0400, Tom spot Callaway wrote:
On 10/26/2010 03:09 PM, Don Zickus wrote:
On Tue, Oct 26, 2010 at 02:10:23PM -0400, Dave Jones wrote:
kernel.x86_64: W: dangling-relative-symlink /lib/modules/2.6.36-1.fc15.x86_64/build ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
(It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in kernel, but the symlink it points to is in kernel-devel. Is there a reason that the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?)
We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed.
I think the problem was the -devel package could be installed without a kernel package behind it making it awkward to install a symlink. Even if you just dropped the symlink on the floor, installing the kernel later would never re-create the symlink leaving things broken.
IIRC, the dangling symlink was the lesser of two evils.
Well, all the real "meat" is in kernel-devel, except for the /lib/modules/%{version}-%{release}.%{_arch}/build symlink which is in kernel. My point was that it seems to make sense to just put that symlink in kernel-devel as well, that way, you either have kernel-devel installed (and have all the files and the symlink) or you don't.
Not that I feel like arguing to save dangling symlink, what happens in the case when you install kernel-devel-$KERNVER but there is no kernel-$KERNVER installed to match? Does the rpm fail because /lib/modules/$KERNVER doesn't exist? Or are we going to add a dependency to prevent that from happening?
Cheers, Don
On Wed, Oct 27, 2010 at 11:02:15AM -0400, Don Zickus wrote:
On Wed, Oct 27, 2010 at 10:02:10AM -0400, Tom spot Callaway wrote:
On 10/26/2010 03:09 PM, Don Zickus wrote:
On Tue, Oct 26, 2010 at 02:10:23PM -0400, Dave Jones wrote:
kernel.x86_64: W: dangling-relative-symlink /lib/modules/2.6.36-1.fc15.x86_64/build ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
(It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in kernel, but the symlink it points to is in kernel-devel. Is there a reason that the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in kernel-devel?)
We flip-flopped on this a few years ago. It used to be that way iirc, but I'm not recalling the exact reasoning for why it changed.
I think the problem was the -devel package could be installed without a kernel package behind it making it awkward to install a symlink. Even if you just dropped the symlink on the floor, installing the kernel later would never re-create the symlink leaving things broken.
IIRC, the dangling symlink was the lesser of two evils.
Well, all the real "meat" is in kernel-devel, except for the /lib/modules/%{version}-%{release}.%{_arch}/build symlink which is in kernel. My point was that it seems to make sense to just put that symlink in kernel-devel as well, that way, you either have kernel-devel installed (and have all the files and the symlink) or you don't.
Not that I feel like arguing to save dangling symlink, what happens in the case when you install kernel-devel-$KERNVER but there is no kernel-$KERNVER installed to match? Does the rpm fail because /lib/modules/$KERNVER doesn't exist? Or are we going to add a dependency to prevent that from happening?
kernel-{,foo-}devel would have to also provide /lib/modules/<kver>/. Requiring matching kernels to be installed would be crazy. But I'm not particularly wild about all kernel-devel packages putting down /lib/modules/<kver>/ directories just to put symlinks in. Personally, I'd just let the dangling symlinks be, but the proper thing is probably to move them into the -devel bits and have those also own /lib/modules/<kver>/ .
On 10/27/2010 11:02 AM, Don Zickus wrote:
Not that I feel like arguing to save dangling symlink, what happens in the case when you install kernel-devel-$KERNVER but there is no kernel-$KERNVER installed to match? Does the rpm fail because /lib/modules/$KERNVER doesn't exist? Or are we going to add a dependency to prevent that from happening?
I think that in this situation, it is permissable for both kernel and kernel-devel to own /lib/modules/$KERNVER. I'd rather have that duplicate directory ownership than a dangling symlink, and the Packaging Guidelines permit it.
~spot
On Thu, Oct 28, 2010 at 10:50:25AM -0400, Tom spot Callaway wrote:
On 10/27/2010 11:02 AM, Don Zickus wrote:
Not that I feel like arguing to save dangling symlink, what happens in the case when you install kernel-devel-$KERNVER but there is no kernel-$KERNVER installed to match? Does the rpm fail because /lib/modules/$KERNVER doesn't exist? Or are we going to add a dependency to prevent that from happening?
I think that in this situation, it is permissable for both kernel and kernel-devel to own /lib/modules/$KERNVER. I'd rather have that duplicate directory ownership than a dangling symlink, and the Packaging Guidelines permit it.
I didn't realize rpm would allow it. Let's try it then and see who screams. :-)
Cheers, Don
Hi,
On 10/26/2010 08:10 PM, Dave Jones wrote:
Spot went through this bug that has been around forever, and wrote up some review comments. I cleaned up some of the low hanging fruit, but there's still a few that I'm uncertain on. input welcomed.
<snip>
kernel.x86_64: W: no-documentation
(At a minimum, COPYING should be present as %doc with the GPLv2 terms.)
I'm not sure this makes sense when we have a kernel-doc package. Though I note we don't have COPYING in there either.
Well, given that kernel-doc is not a dependency of the kernel itself (so the kernel can be installed without kernel-doc), having COPYING inside kernel-doc does not help. A package MUST either ship its license text as %doc, or require a package which does (ie a foo-devel which requires foo, does not need to ship its license text as foo already does).
So all kernel (sub) packages must include COPYING unless they require the main kernel package (and that included COPYING), also see:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines Esp. the following section:
Subpackage Licensing
If a subpackage is dependent (either implicitly or explicitly) upon a base package (where a base package is defined as a resulting binary package from the same source RPM which contains the appropriate license texts as %doc), it is not necessary for that subpackage to also include those license texts as %doc.
However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts (as present in the source) which are applicable to the files contained within the subpackage.
********
More over in general packages with a -doc subpackage include the basic docs in the main package and more extensive docs in the -doc package, so looking at the kernel source tree, it would seem that COPYING, CREDITS, MAINTAINERS, README and REPORTING-BUGS all should be in the main package %doc.
Although maybe we should not include REPORTING-BUGS, assuming that we want Fedora users to always go through Fedora bugzilla rather then directly report upstream.
Regards,
Hans
kernel@lists.fedoraproject.org
-
Bill Nottingham -
Dave Jones -
Don Zickus -
Hans de Goede -
Jarod Wilson -
Roland McGrath -
Tom Callaway