On Thu, 2005-06-30 at 17:11 +0300, Ville Skyttä wrote:
On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote:
I split the package in a userland package that creates a %{name}-kmsrc.rpm that is used by the kernel-module-package as source. Something like this would be neat package like nvidia als ati drivers where a single srpm is quite big if you want to rebuild only the kernel-module
I don't see the point of the kmsrc package.
ACK.
If you want to optimize SRPM download sizes, why not just supply a separate trimmed-down tarball containing only the kernel module bits in the kernel module SRPM (and include comments in the specfile how it was created from the upstream dist tarball, or include a script to do it in the source rpm)? And if you want, another similar trimmed one in the userland SRPM containing only the non-kernel-module parts.
Actually, I fail to see where this approach _really_ reduces bandwidth requirements.
Users who are rebuilding the rpms, should learn to download the srpm once. Afterwards, they'll have it "on disk" and don't have to re-download it again.
I would expect the high rate of downloads of kernel-module-*src.rpms you might be seeing at Livna to originate from delays between kernel releases in FC and kernel-module releases at Livna.
Further, the sources and the build routines for the kernel modules are now split into two packages, which means also extra work and care from the maintainer.
Agreed. Also, it might not always be possible or not possible with further effort, sometimes for technical reasons (Makefiles, build infrastructure etc.), sometimes for licensing reasons ("Unmodified sources").
Isn't this just more work for both maintainers and end users?
Not for end users. They'd only see a kernel-module*.src.rpm and will not know about the fact it had been split out elsewhere. But .. no matter if the source are split into userland/kernel srpms they will have to rebuild _one_ srpm.
Ralf