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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <slack@xxxxxxxxxxxxxxx>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
