On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway
wrote:
> On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
> >
> > Leaving everything else aside for a sec, this doesn't screw up bugzilla if
> > you do it as a subpackage -- same way kernel and kernel-smp don't.
>
> I think we have to assume that there will be some kernel-module packages
> that just consist of drivers, with no extra user space addons.
Just for the record as we don't seem to be needing this stuff: does not
matter, those could be implemented so that the SRPM would produce _only_
one binary "subpackage".
One spec file can produce packages like the following IIRC:
openafs-V-R
openafs-client-V-R
kernel-module-openafs-V-R.%{cleankver}
openafs-devel-V-R
> > My only concern here is maybe particular to openafs -- the
kernel module
> > source isn't distributed separately from the other library/userspace/gunk.
I
> > guess I *could* make an openafs.src.rpm and a separate
> > openafs-kernel.src.rpm both containing the same source tarball, but that
> > seems kinda wrong. On the other hand, hey, maybe it isn't.
>
> Or you could make the userspace gunk in a subpackage. No reason that
> kernel-module-openafs can't generate both kernel-module-openafs and
> openafs packages.
What about archs? We probably don't want i586 and i686 userland openafs
stuff, but just i386. Choices:
<insert AFS is special here>
1) Just ship userland as i586 and i686 too
2) Split userland and module SRPMS
3) Conditionalize whether to build the modules or the userland or both
based on some passed in build options
(
rpm.livna.org uses "--without modules" and "--without userland")
4) Hardcode our assumptions based on arch somewhere, eg. if target=i586
or i686, no userland will be built, and if target=i386, no modules
will be built
My openafs packages only build the userland packages if the current arch
you are building for is a basearch. Conversely, it does not build a
kernel module for the i386 arch.
Yes *sigh* my spec has a list of basearchs hard coded in.
This makes the most since, however it would be nice for RPM to provide
basearch information rather than hard coding it.
2) gets my vote.
Beleive me. This is very yucky. You really don't want to.
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <slack(a)quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89