On Tue, Jul 31, 2007 at 07:11:05PM -0700, Roland McGrath wrote:
(I say this, but then, I wrote the glibc makefiles as a child, so
my judgment is clearly suspect, and my breeding a lost cause.)
What is this, a counselling list now? :-)
I think this is a nice cleanup on its own. The reason I actually
did it is that the debuginfo package details will have to change
soon when a new find-debuginfo.sh comes in rpm, which is cleaned up
generally and does new magic for the build-id stuff. I really
don't want to have to start dicking with that before it's
consolidated into only one place I have to touch.
I've verified that this is a no-op vs the 0.61 build. i.e., it
generates rpms with the same files and same rpm magic, modulo a few
typo fixes and cosmetic cleanups/consolidation of rpm script fragments.
In the absence of frothing vitriol, I will commit this after
f8-test1 has sailed.
My initial reaction was one of shock, but this could just be
reaction to the sheer size of the diff. I'll take a look at
the post-application specfile later.
One thing I did notice though which seemed non-obvious to me..
+# First the auxiliary packages of the main kernel package.
+%kernel_devel_package
+%kernel_debuginfo_package
+
+
+# Now, each variant package.
+
+%define variant_summary The Linux kernel compiled for SMP machines
+%kernel_variant_package -n SMP smp
Do -debuginfo packages for variants get produced automatically?
I'm assuming yes based on this part of the macro..
+%if %{with_debuginfo}\
+%ifnarch noarch\
+%{expand:%%files %{?2:%{2}-}debuginfo}\
+%defattr(-,root,root)\
+%if %{elf_image_install_path} != \
+%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\
+%endif\
+%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\
+%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\
+%{?-a:%{debuginfodir}%{-a*}.debug}\
+%endif\
+%endif\
+%endif\
but for some reason, it doesn't sit right in my head.
I've no real fundamental objection to this, but don't leave the country
or have any accidents for a while after it goes in :-)
Just as when Jarod did the versioning overhaul, if something goes awry,
you'd probably be able to figure out the problem quicker than those
getting up to speed on what you've done so far.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list