CC fedora-packaging because this concerns kernel-module-packaging
Am Dienstag, den 23.08.2005, 01:18 -0400 schrieb seth vidal:
On Sat, 2005-08-20 at 12:17 +0200, Thorsten Leemhuis wrote:
Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams:
Quite a few things will change for plague 0.4: [...] If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras Infrastructure.
What is the current status of passing special options to the actual rpmbuild call? We should have those for building kernel-modules because building kernel-modules for a lot of different kernels would be much easier if no changes to the actual kernel-module-specfile are needed. In the current KernelModuleProposal-Example2 (*1) this is realized by:
%{!?kver: %define kver %(uname -r)} [...] make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C driver
So if someone builds the src.rpm at home it is rebuild for the current kernel. When build with mock the buildsystem should defined kver. Something like:
for kernel in <list of target kernels [example: current-kernel.i586 current-kernel.i686 current-kernel-smp.i586]> do mock build /path/to/srpm --define "kver $kernel" done
AFACS we need support for this in both mock and plague (or is something like that already possible? mach can pass options to rpmbuild, mock can't iirc)
I do not think that adding this into mock or rpmbuild is a good idea, honestly.
For other packages I agree. Kernel-modules should be a exception IMHO.
If the package won't built w/o arbitrary defines then we'll have a devil of a time figuring out how to REBUILD it later.
It builds for the normal user without arbitrary defines. And even better: It automatically builds what you probably want, because with the above it builds the kernel-module for the currently running kernel. If you get a random kernel-module.src.rpm where kver ist hardcoded you have to edit it each time to get compile against a new kernel.
BTW, this is in all three proposals in http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal
If we all agree that we don't like passing arguments to rpmbuild then we should restart the kernel-module-discussion on fedora-packaging.
CU thl
For other packages I agree. Kernel-modules should be a exception IMHO.
I worry that having them as the exception means we have to do the code anyway which makes it a slippery-damn-slope to all packages using arbitrary defines.
It builds for the normal user without arbitrary defines. And even better: It automatically builds what you probably want, because with the above it builds the kernel-module for the currently running kernel. If you get a random kernel-module.src.rpm where kver ist hardcoded you have to edit it each time to get compile against a new kernel.
why doesn't it automatically build for whatever the highest installed kernel-devel or highest installed kernel package is?
-sv
Am Dienstag, den 23.08.2005, 01:59 -0400 schrieb seth vidal:
For other packages I agree. Kernel-modules should be a exception IMHO.
I worry that having them as the exception means we have to do the code anyway which makes it a slippery-damn-slope to all packages using arbitrary defines.
:)
It builds for the normal user without arbitrary defines. And even better: It automatically builds what you probably want, because with the above it builds the kernel-module for the currently running kernel. If you get a random kernel-module.src.rpm where kver ist hardcoded you have to edit it each time to get compile against a new kernel.
why doesn't it automatically build for whatever the highest installed kernel-devel or highest installed kernel package is?
And who decides when a module for a smp-kernel is build and when not? Doing this with
%build buildfunc() { make something } %ifarch i686 x86_64 ppc build up build smp %else build up %endif
in the spec is really ugly (and not possible with our current scheme afaics -- need to try, but i suspect it won't work).
CU thl
On Tue, Aug 23, 2005 at 01:59:27AM -0400, seth vidal wrote:
why doesn't it automatically build for whatever the highest installed kernel-devel or highest installed kernel package is?
One of the problems is that the build system doesn't know what kernels an end user may be running. Therefore, you've got to
a) be able to have the end user rebuild for whatever kernel they're running (easy, works that way today)
b) if the driver is needed at install time, the build system needs to provide pre-builts for the installer (and CD media) kernel.
(optionally) c) have the build system build binaries for each of the released errata kernels too, so you don't require a kernel upgrade in order to get a given module that matches.
I'm not sure how optional c) really is though. Depends on how easy you want to make life for your system administrators to not have to do a) themselves all the time.
-Matt
packaging@lists.fedoraproject.org
-
Matt Domsch -
seth vidal -
Thorsten Leemhuis