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