Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad)

[Ignacio Vazquez-Abrams]

On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > As an aside, I didn't think Extras was ready to tackle the issue of
>  > kernel module packages yet.
>  
>  Right, at least three issues remain: how to name the modules, how to
>  make depsolvers do the right thing with them, and how to request builds
>  for i586 and i686 from the build system for the same package. 
Screw i586 for now. As for naming, the kernel version needs to be stored
*somewhere*. And we need to finalize the naming issue before we can
decide what behavior depsolvers need.

>  But we should really fix the remaining issues with kernel module
> builds,
>  I'd like to get LIRC modules shipped too, and there may be other stuff
>  queued up from others.  Anybody willing to (re)start or join this
>  discussion somewhere?  fedora-packaging? 
Works for me. Here's my first submission:

https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00965.html

I've had to make a few changes for FC4, and I'll post those later today
when I get a chance.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Ville Skyttä]

On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
>  On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > > As an aside, I didn't think Extras was ready to tackle the issue of
>  > > kernel module packages yet.
>  > 
>  > Right, at least three issues remain: how to name the modules, how to
>  > make depsolvers do the right thing with them, and how to request builds
>  > for i586 and i686 from the build system for the same package.
>  
>  Screw i586 for now. 
I'll screw it once the i586 kernel is screwed from FC :)  Seriously,
there are cases where i586 and external kernel modules are a valid
scenario; for example I think a lot of HTPC/PVR boxes run some VIA CPUs
that don't work with the i686 kernel, and having LIRC modules for their
remote controls is kind of essential.

But anyway, even in the hypothetical case that i586 would be ignored,
I'm not 100% sure how to implement i686 build only for the ix86 family
in the build system, while keeping in mind that the modules should
probably be built for x86_64 and ppc too.  %ifarch %{ix86} \ BuildArch:
i686 \ %endif?

>  As for naming, the kernel version needs to be stored
>  *somewhere*. 
Dependencies, surely, but it does not _have_ to be in the package's NVR,
as demonstrated by the external kernel module packages in FC4 (eg.
GFS-kernel).  Having it in the NVR somewhere is useful for humans, and
it can be (ab?)used to get depsolvers to do "stuff".

>   And we need to finalize the naming issue before we can
>  decide what behavior depsolvers need. 
Possibly.

[Ralf Corsepius]

On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
>  On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
>  > On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > > > As an aside, I didn't think Extras was ready to tackle the issue of
>  > > > kernel module packages yet.
>  > > 
>  > > Right, at least three issues remain: how to name the modules, how to
>  > > make depsolvers do the right thing with them, and how to request builds
>  > > for i586 and i686 from the build system for the same package.
>  > 
>  > Screw i586 for now.
>  
>  I'll screw it once the i586 kernel is screwed from FC :)  Seriously,
>  there are cases where i586 and external kernel modules are a valid
>  scenario;  
As architectures actually are switched outside of rpm-specs 
(rpmbuild --target=..) this isn't a packaging issue, but actually is a
build system issue.

I.e. the buildsystem has to be equipped with means to specify
architectures, because rpm specs can't handle it.

Ralf

[Ignacio Vazquez-Abrams]

On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote:
>  On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
>  > On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
>  > > On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  > > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > > > > As an aside, I didn't think Extras was ready to tackle the issue
> of
>  > > > > kernel module packages yet.
>  > > > 
>  > > > Right, at least three issues remain: how to name the modules, how to
>  > > > make depsolvers do the right thing with them, and how to request builds
>  > > > for i586 and i686 from the build system for the same package.
>  > > 
>  > > Screw i586 for now.
>  > 
>  > I'll screw it once the i586 kernel is screwed from FC :)  Seriously,
>  > there are cases where i586 and external kernel modules are a valid
>  > scenario; 
>  As architectures actually are switched outside of rpm-specs 
>  (rpmbuild --target=..) this isn't a packaging issue, but actually is a
>  build system issue.
>  
>  I.e. the buildsystem has to be equipped with means to specify
>  architectures, because rpm specs can't handle it. 
It's also an rpmdb issue as you (or at least *I*) can't have
kernel-devel.i586 and kernel-devel.i686 installed simultaneously even
though there are no file conflicts between the packages.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Jack Neely]

On Tue, Jun 28, 2005 at 12:35:14PM -0400, Ignacio Vazquez-Abrams wrote:
>  On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote:
>  > On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
>  > > On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
>  > > > On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  > > > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > > > > > As an aside, I didn't think Extras was ready to tackle the
> issue of
>  > > > > > kernel module packages yet.
>  > > > > 
>  > > > > Right, at least three issues remain: how to name the modules, how to
>  > > > > make depsolvers do the right thing with them, and how to request
> builds
>  > > > > for i586 and i686 from the build system for the same package.
>  > > > 
>  > > > Screw i586 for now.
>  > > 
>  > > I'll screw it once the i586 kernel is screwed from FC :)  Seriously,
>  > > there are cases where i586 and external kernel modules are a valid
>  > > scenario; 
>  > As architectures actually are switched outside of rpm-specs 
>  > (rpmbuild --target=..) this isn't a packaging issue, but actually is a
>  > build system issue.
>  > 
>  > I.e. the buildsystem has to be equipped with means to specify
>  > architectures, because rpm specs can't handle it.
>  
>  It's also an rpmdb issue as you (or at least *I*) can't have
>  kernel-devel.i586 and kernel-devel.i686 installed simultaneously even
>  though there are no file conflicts between the packages.
>  
>  -- 
>  Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
>  http://fedora.ivazquez.net/
>  
>  gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 
To me this is really a multilib issue.  Multiple packages with the same
name installed but built for different arches.  The spec file needs to
be able to require the kernel-devel packages of the same arch as the
current build.

Jack Neely

>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging 

-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Ville Skyttä]

On Tue, 2005-06-28 at 15:09 -0400, Jack Neely wrote:

>  The spec file needs to
>  be able to require the kernel-devel packages of the same arch as the
>  current build. 
Not a problem, one solution already mentioned in this thread:
https://www.redhat.com/archives/fedora-packaging/2005-June/msg00020.html

[Ignacio Vazquez-Abrams]

On Tue, 2005-06-28 at 18:42 +0300, Ville Skyttä wrote:
>  But anyway, even in the hypothetical case that i586 would be
> ignored,
>  I'm not 100% sure how to implement i686 build only for the ix86 family
>  in the build system, while keeping in mind that the modules should
>  probably be built for x86_64 and ppc too.  %ifarch %{ix86} \ BuildArch:
>  i686 \ %endif? 
Clearly the kernel buildsystem (I can see this being separate from
Plague, at least in the beginning) would have to be able to parse
BuildArch properly in order to determine which archs it should be built
for. It *may* be possible to leverage rpmlib for this, but I don't have
time to look into it atm.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Ville Skyttä]

On Tue, 2005-06-28 at 12:39 -0400, Ignacio Vazquez-Abrams wrote:

>  Clearly the kernel buildsystem (I can see this being separate from
>  Plague, at least in the beginning) 
And I can see _that_ happening sometime around FC-8 ;)

AFAIK there's no absolute _need_ to have a separate buildsystem, not
even because of the current impossibility to have both i586 and i686
kernel-devel for the same kernel installed at the same time.  Just
specify for example

   BuildRequires: kernel-devel-%{_target_cpu} = %{kernel}

in the module specfile (where %{kernel} is the "uname -r" output for the
target kernel, and the correct --target has been passed to the build),
and let the depsolver do its job.  There are no kernel-devel packages
included in the default minimal build roots that could screw this up,
right?

If so, a simple (from the module packager POV, dunno about the buildsys
side) extension to the current CVS target could be for example:

   make build ARCH="i586 i686 x86_64 ppc"

This could be a useful feature for other packages than kernel module
ones too, should we ever want to ship eg. something built for i686 in
the i386 repo.

[Jack Neely]

>  > As for naming, the kernel version needs to be stored
>  > *somewhere*.
>  
>  Dependencies, surely, but it does not _have_ to be in the package's NVR,
>  as demonstrated by the external kernel module packages in FC4 (eg.
>  GFS-kernel).  Having it in the NVR somewhere is useful for humans, and
>  it can be (ab?)used to get depsolvers to do "stuff".
>   
Your kernel module should require the kernel it was built for.  Its
simple and already common practice.  I already have depresolver code
that examines the EVR of any Requires that are in the list of packages
considered kernel packages.

I strongly oppose having the kernel version/type in the packages NVR.
The depresolver should be smart enough to know when to install kernel
module packages and in what conditions to erase them.  Kernel module
packages are never upgraded.

>  >  And we need to finalize the naming issue before we can
>  > decide what behavior depsolvers need.
>   
I prefer the naming scheme of <foo>-kernel

However the depresolver should not hinge off of a specific naming
scheme.  Kernel modules should Provide kernel-modules to trigger the
extra functionality in the depresolver.

Jack Neely

-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Tom Callaway]

On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote:
>  On Tue, 2005-06-28 at 18:04 +0300, Ville Skyttä wrote:
>  > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote:
>  > > As an aside, I didn't think Extras was ready to tackle the issue of
>  > > kernel module packages yet.
>  > 
>  > Right, at least three issues remain: how to name the modules, how to
>  > make depsolvers do the right thing with them, and how to request builds
>  > for i586 and i686 from the build system for the same package.
>  
>  Screw i586 for now. As for naming, the kernel version needs to be stored
>  *somewhere*. And we need to finalize the naming issue before we can
>  decide what behavior depsolvers need. 
Actually, no. I'm not going to standardize kernel module packaging
_UNTIL_ at least yum is fixed.

Let me reiterate some points that I have made in the past:

- I do not plan to overload the %{name} value for kernel module
packages. This means that we will NOT be shoving the kernel version in
%{name}. Its ugly, it screws up bugzilla, breaks existing packaging
guidelines, and is altogether wrong.

- Given that, we WILL need to put the kernel version (in some part) in
either %{version} or %{release}. Let me explain why:

On SMP systems, at a bare minimum, there will be two kernels installed:

kernel-smp-2.6.12-1.1400_FC5
kernel-2.6.12-1.1400_FC5

If we do not use kernel version in either %{version} or %{release},
we'll have no way to generate two packages with unique
%{name}-%{version}-%{release} values.

We have to assume that each installed kernel will want to have a
matching module addon installed for it.

I originally proposed (back in March) that we put the kernel version in
Release. This is a slightly revised proposal.

Name: kernel-module-openafs
(where the value in the Name field is the name of the module, prepended
with "kernel-module-")
Version: 1.1
(where the value in the Version field is equivalent to the kernel module
version, NOT the kernel version we're building against (in this example,
"1", followed by the build revision, in this example ".1")
Release: %{kver}
(Where %{kver} is the kernel we're building against)
Requires: kernel-%{_target_cpu} = %{kver}
BuildRequires: kernel-devel-%{_target_cpu} = %{kver}

%{kver} gets passed by the buildsystem, for each kernel found in the
branch for which that package is being built. So, for our example
kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp,
respectively. FC4 and newer kernels have this value in the provides for
"kernel-%{arch}", so it should not be too difficult for the build system
to figure out the correct value for %{kver} from the target kernel
package.

There is no need to use dist tags here, since %{kver} includes the dist
name.

If a bugfix needs to be made to the package, then the .1 (build
revision) is incremented. If a new version of the kernel driver is
released, then the first part of the Version is incremented, and the
build revision is reset to .1 (if it is not .1).

So, after the buildsystem does its thing, we've generated two new binary
rpms:

kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm
kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm

Since no previous packages with those n-v-r's exist, yum installs them,
just as it would kernels, doing the equivalent of an rpm -i action.

Now, on the system we have all four packages installed:

kernel-2.6.12-1.1400_FC5
kernel-module-openafs-1.1-2.6.12-1.1400_FC5
kernel-smp-2.6.12-1.1400_FC5
kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp

But wait, I've found a bug in kernel-module-openafs. Easy enough to fix,
I patch it away, increment my build revision to .2, and we now have
these new packages available:

kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm
kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm

But, here yum doesn't know what to do. We can't do a -i, those packages
would conflict with the existing kernel-module-openafs packages. We
can't do a -U, because then we'd only end up with one
kernel-module-openafs package on the system. What we need yum to do is a
special operation that does the following (only for kernel-module
packages):

- Does any kernel-module-openafs package exist on the system with the
same %{release}?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).

After this process, the system has:

kernel-2.6.12-1.1400_FC5
kernel-module-openafs-1.2-2.6.12-1.1400_FC5
kernel-smp-2.6.12-1.1400_FC5
kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp

Now, if someone is willing and able to write the exception case needed
for yum in kernel-module-* packages, then I think we can document the
remaining standard bits, duct tape the necessary logic into the
buildsystem, and start doing kernel-module-* packages for FC4 and devel.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Ignacio Vazquez-Abrams]

On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway wrote:
>  Version: 1.1
>  (where the value in the Version field is equivalent to the kernel module
>  version, NOT the kernel version we're building against (in this example,
>  "1", followed by the build revision, in this example ".1") 
>  If a bugfix needs to be made to the package, then the .1 (build
>  revision) is incremented. If a new version of the kernel driver is
>  released, then the first part of the Version is incremented, and the
>  build revision is reset to .1 (if it is not .1). 
Where do you propose that we put the version number of the module
itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in
that case?

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Tom Callaway]

On Tue, 2005-06-28 at 20:56 -0400, Ignacio Vazquez-Abrams wrote:
>  On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway
> wrote:
>  > Version: 1.1
>  > (where the value in the Version field is equivalent to the kernel module
>  > version, NOT the kernel version we're building against (in this example,
>  > "1", followed by the build revision, in this example ".1")
>  
>  > If a bugfix needs to be made to the package, then the .1 (build
>  > revision) is incremented. If a new version of the kernel driver is
>  > released, then the first part of the Version is incremented, and the
>  > build revision is reset to .1 (if it is not .1).
>  
>  Where do you propose that we put the version number of the module
>  itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in
>  that case? 
Yes. If you need to use the version number of the module itself without
a build revision, then we can use something like:

Provides: kernel-module-openafs-version = 0.6.3

We could also standardize on a macro, something like %{modulever},
define it at the top, then use it throughout the spec file for clarity.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Matthew Miller]

On Tue, Jun 28, 2005 at 08:14:22PM -0500, Tom 'spot' Callaway wrote:
>  Yes. If you need to use the version number of the module itself
> without
>  a build revision, then we can use something like:
>  Provides: kernel-module-openafs-version = 0.6.3 
This seems yicky.

What if we do this, and so we're providing kernel-module-openafs-version =
1.3.84, and then the upstream decides to do a bugfix release and call it
1.3.84.1? With your scheme, our old kernel module was *already* 1.3.84.1.

Why *not* just put package release #s in the package release #?

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Matthew Miller]

On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote:
>  - I do not plan to overload the %{name} value for kernel module
>  packages. This means that we will NOT be shoving the kernel version in
>  %{name}. Its ugly, it screws up bugzilla, breaks existing packaging
>  guidelines, and is altogether wrong. 
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.


[...]

Oh wait, something else I want to comment on --

>  Version: 1.1
>  (where the value in the Version field is equivalent to the kernel module
>  version, NOT the kernel version we're building against (in this example,
>  "1", followed by the build revision, in this example ".1") 

Ouch -- this won't work. The .1 here will be very very confusing. For
openafs 1.3.84, the _package_ release shouldn't be 1.3.84.1 or whatever --
it'll make it hard to match up to the actual source. I think this is *worse*
than putting the version in the name.

I think it's better to have this in the release:

>  Release: %{kver}
>  (Where %{kver} is the kernel we're building against)
>  Requires: kernel-%{_target_cpu} = %{kver}
>  BuildRequires: kernel-devel-%{_target_cpu} = %{kver} 

Release: %{realpackagerelease}.%{kver}


'cause hey, that's what the Release tag is supposed to be fore*.

>  %{kver} gets passed by the buildsystem, for each kernel found in the
>  branch for which that package is being built. So, for our example
>  kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, 
Oh, there's another problem -- can't have a "-" in the release #.


>  respectively. FC4 and newer kernels have this value in the provides
> for
>  "kernel-%{arch}", so it should not be too difficult for the build system
>  to figure out the correct value for %{kver} from the target kernel
>  package. 
Passed in in a loop from the buildsystem? That seems decent.

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.


[...]
>  kernel-module-openafs package on the system. What we need yum to do
> is a
>  special operation that does the following (only for kernel-module
>  packages):
>  
>  - Does any kernel-module-openafs package exist on the system with the
>  same %{release}?
>  - If yes, remove it (rpm -e). If no, continue.
>  - Install new package (rpm -i). 
Haven't thought this through completely, but there's one more factor too:
kernel-module-openafs-1.3.84 will be required by the openafs-client package.

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Tom Callaway]

On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
>  On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway
> wrote:
>  > - I do not plan to overload the %{name} value for kernel module
>  > packages. This means that we will NOT be shoving the kernel version in
>  > %{name}. Its ugly, it screws up bugzilla, breaks existing packaging
>  > guidelines, and is altogether wrong.
>  
>  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.

>  I think it's better to have this in the release:
>  
>  > Release: %{kver}
>  > (Where %{kver} is the kernel we're building against)
>  > Requires: kernel-%{_target_cpu} = %{kver}
>  > BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
>  
>  
>  Release: %{realpackagerelease}.%{kver} 
OK, so lets say we do this.

In this case, we have %{kver} in %{release} to keep %{release} unique
(and thus, have unique NVR). However, we can no longer just use
%{release} as our check variable in yum. In this scenario, we need to
instead make yum check some sort of "magic" provides that only
kernel-module packages will have (not as much of a hack as might be
thought).

In the spec, we put:

Provides: kernel-module-openafs-kver = %{kver}

Basically, to modify my original yum logic path:

- Does any kernel-module-openafs package exist on the system with the
same kernel-module-openafs-kver?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).

>  Oh, there's another problem -- can't have a "-" in
> the release #. 
%define cleankver %(echo %{kver} | sed s,-,_,g)

>  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.

You can override the version and release for the openafs package.

>  Haven't thought this through completely, but there's one more
> factor too:
>  kernel-module-openafs-1.3.84 will be required by the openafs-client package. 
Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps
the remove, knowing that the install is coming right afterward.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[seth vidal]

>  > Haven't thought this through completely, but there's one
> more factor too:
>  > kernel-module-openafs-1.3.84 will be required by the openafs-client package.
>  
>  Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps
>  the remove, knowing that the install is coming right afterward. 

umm, what?

no we won't.

we're not adding --nodeps or that tsflag into yum.

-sv

[Tom Callaway]

On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:

>  > > Requires: kernel-%{_target_cpu} = %{kver} 
>  In the spec, we put:
>  
>  Provides: kernel-module-openafs-kver = %{kver} 
Or, we just leave that nonsense out and key off the Requires:
kernel-%{_target_cpu}

So, once more:
- Does any kernel-module-openafs package exist on the system that
requires the same kernel-%{_target_cpu} = %{kver} as me?
- If yes, remove it (rpm -e --nodeps). If no, continue.
- Install new package (rpm -i)

I suspect this is very close to Jack's existing patch.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[seth vidal]

On Wed, 2005-06-29 at 08:42 -0500, Tom 'spot' Callaway wrote:
>  On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway
> wrote:
>  
>  > > > Requires: kernel-%{_target_cpu} = %{kver}
>  
>  > In the spec, we put:
>  > 
>  > Provides: kernel-module-openafs-kver = %{kver}
>  
>  Or, we just leave that nonsense out and key off the Requires:
>  kernel-%{_target_cpu}
>  
>  So, once more:
>  - Does any kernel-module-openafs package exist on the system that
>  requires the same kernel-%{_target_cpu} = %{kver} as me?
>  - If yes, remove it (rpm -e --nodeps). If no, continue.
>  - Install new package (rpm -i)
>  
>  I suspect this is very close to Jack's existing patch. 
I suspect that were NOT adding --nodeps.

no matter what.

think again if you think we are.

-sv

[Jack Neely]

On Wed, Jun 29, 2005 at 08:42:10AM -0500, Tom 'spot' Callaway wrote:
>  On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway
> wrote:
>  
>  > > > Requires: kernel-%{_target_cpu} = %{kver}
>  
>  > In the spec, we put:
>  > 
>  > Provides: kernel-module-openafs-kver = %{kver}
>  
>  Or, we just leave that nonsense out and key off the Requires:
>  kernel-%{_target_cpu}
>  
>  So, once more:
>  - Does any kernel-module-openafs package exist on the system that
>  requires the same kernel-%{_target_cpu} = %{kver} as me?
>  - If yes, remove it (rpm -e --nodeps). If no, continue.
>  - Install new package (rpm -i)
>  
>  I suspect this is very close to Jack's existing patch. 
Very.  I'm missing a detail or two but I'll get that out tonight.

Jack

>  
>  ~spot
>  -- 
>  Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
>  Fedora Extras Steering Committee Member (RPM Standards and Practices)
>  Aurora Linux Project Leader: http://auroralinux.org
>  Lemurs, llamas, and sparcs, oh my!
>  
>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging 
-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Jack Neely]

Folks,

Attached is a patch that implements some of the kernel magic needed by
Yum to work with kernel modules as decided on fedora-packaging-list.
This keys off of kernel modules requiring

    kernel-%{_target_cpu} = %{kver}

Couple points of note:

* You must still have your kernel modules provide "kernel-modules" to
  enable the install only behavior.  However, the code uses the package
  name "kernel-module-foo" to identify if this is a kernel module.

* The next question is when you do "yum install kernel-module-openafs" 
  which packages do we apply to the system?  Not covered by this patch.

Jack
-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Tom Callaway]

On Thu, 2005-06-30 at 00:06 -0400, Jack Neely wrote:
>  Folks,
>  
>  Attached is a patch that implements some of the kernel magic needed by
>  Yum to work with kernel modules as decided on fedora-packaging-list.
>  This keys off of kernel modules requiring
>  
>      kernel-%{_target_cpu} = %{kver}
>  
>  Couple points of note:
>  
>  * You must still have your kernel modules provide "kernel-modules" to
>    enable the install only behavior.  However, the code uses the package
>    name "kernel-module-foo" to identify if this is a kernel module.
>  
>  * The next question is when you do "yum install kernel-module-openafs" 
>    which packages do we apply to the system?  Not covered by this patch. 
As far as I'm concerned, we look at what kernels are on the system (in
the rpmdb), and try our best to match them all against the
kernel-module-openafs packages in the repo. When we find a kernel for
which no kernel-module-openafs package exists in the repo, we throw a
warning, but don't exit, and install the ones we do find matches for.

Warning: No kernel-module-openafs package was found for
kernel-2.6.12-1.1400spot

I really can't think of a situation in which we would not want to
install an addon kernel-module for all kernels installed via rpm.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Tom Callaway]

On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote:

>  Shouldn't be a problem. We'll just pretend we're anaconda
> and --nodeps
>  the remove, knowing that the install is coming right afterward. 
In fact, its not even a problem.

skvidal> it's a simultaneous transaction
skvidal> if bar (installed) requires foo
skvidal> and you're removing baz (provides foo)
skvidal> and installing quux(provides foo)
skvidal> and it is all in one transaction then there are no broken dependencies
spot> ok. :) then its a non issue. 
skvidal> there's no need for --nodeps
skvidal> right but I feel it is a necessity to smack any discussion of --nodeps at all
times :)

Consider me duly smacked.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Matthew Miller]

On Wed, Jun 29, 2005 at 08:48:11AM -0500, Tom 'spot' Callaway wrote:
>  skvidal> and installing quux(provides foo)
>  skvidal> and it is all in one transaction then there are no broken dependencies
>  spot> ok. :) then its a non issue. 
>  skvidal> there's no need for --nodeps 
Okay, just to get this all concrete for me....


On the system, we've got:

  kernel-2.6.11-1.27_FC3
  kernel-2.6.11-1.35_FC3
  kernel-smp-2.6.11-1.27_FC3
  kernel-smp-2.6.11-1.35_FC3

  openafs-1.3.84-1
  openafs-client-1.3.84-1

  kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3smp
  kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3smp

If we add a new kernel, say:

  kernel-2.6.11-1.40_FC3
  kernel-smp-2.6.11-1.40_FC3

Okay, the Magic makes the depsolver pull in 

  kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3smp

and we're all good.

Okay, but now say there's an updated openafs-1.3.85. So we've got to figure
out that:

  kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-1_2.6.11-1.27_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-1_2.6.11-1.35_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-1_2.6.11-1.40_FC3

 (plus smp)

And to complicate things, you also have the potential to have to deal with

  kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3
  kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3

and

  kernel-module-openafs-1.3.85-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3
  kernel-module-openafs-1.3.85-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3
  kernel-module-openafs-1.3.85-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3

.

Maybe this'll all work, but, gah. :)


-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.

[Matthew Miller]

On Wed, Jun 29, 2005 at 08:38:45AM -0500, Tom 'spot' Callaway 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. 
That can work too -- look at the pump RPM, which only generates subpackages
with different names. But I only think this is preferable to putting the
package release number in the version -- my preferences is for kernel and
package release number to both go in the release.


>  > Release: %{realpackagerelease}.%{kver}
>  OK, so lets say we do this.
>  In this case, we have %{kver} in %{release} to keep %{release} unique
>  (and thus, have unique NVR). However, we can no longer just use
>  %{release} as our check variable in yum. In this scenario, we need to 
Right -- anything that wants to do something smart with these packages will
have to be smart about it. I think it's better to require whatever smartness
in as few places as possible, even at the price of requiring more of it in
those places. Redefining what 'version' means to mean "somes the upstream
version, sometimes some numbers we made up" seems a lot worse in general.

And, the "cleanver" thing to get rid of the '-' already requires some
parsing. As much as I hate _ in package names, we could do:

Release: %{realpackagerelease}_%{cleankver}

or maybe

Release: %{realpackagerelease}.kver%{cleankver}

(Ugh, very long and ugly, though.)


>  instead make yum check some sort of "magic" provides that
> only
>  kernel-module packages will have (not as much of a hack as might be
>  thought). 
The more I think about this (Jack's) approach, the more I feel okay about
it. Maybe it's contagious. :)


[...]
>  > 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. 
That seems backwards. Right now, the kernel modules are a subpackage of
the openafs package -- making the package kernel-module-openafs seems like
putting the cart before the horse. (Why would openafs-server be a subpackage
of that, for example?)

>  You can override the version and release for the openafs package.
Except, if we're building for five different kernels, each of those would
then generate the identical openafs-server, openafs-client, and openafs
packages. At the very least, that's a lot of wasted CPU.


>  > Haven't thought this through completely, but there's one
> more factor
>  > too: kernel-module-openafs-1.3.84 will be required by the openafs-client
>  > package.
>  Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps
>  the remove, knowing that the install is coming right afterward. 
Ow, must we?

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 76 degrees Fahrenheit.

[Ville Skyttä]

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".

>  > 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:

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

2) gets my vote.

[Matthew Miller]

On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote:
>  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
>  
>  2) gets my vote. 
For 4), remember that we've also got smp (and in CentOS 4, which I'd
also like to support, hugemem).

#2 has some appeal, particularly since it avoids rebuilding the userland
stuff for every kernel update, but it requires some careful consideration
about the dependency relationship between the userland and module
packages.... (I've been assuming a requires version-release kind of thing,
but on reflection, that'd be *hard* and generally *not* wanted -- but then,
in the cases where it *is* wanted, not possible. Gah.) 

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.

[Jack Neely]

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&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Ignacio Vazquez-Abrams]

On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
>  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 
Indeed. Just give the subpackage its own Release tag.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

[Tom Callaway]

On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote:
>  On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
>  > 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
>  
>  Indeed. Just give the subpackage its own Release tag. 
I honestly don't care which is the base and which is the subpackage. The
biggest issue I see is with arch determination, since they HAVE to be
the same between base and subpackage.

The userland package should only have the userland arch (i386, sparc,
ia64, ppc, x86_64), whereas the kernel-module package needs to exist for
all of these arches (i386, i586, i686, ia64, ppc, ppc64, sparc, sparc64,
x86_64).

I think that overcoming this obstacle may require that the two packages
be built from separate SRPMS. As always, I'm open to suggestions.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Ralf Corsepius]

On Wed, 2005-06-29 at 10:35 -0500, Tom 'spot' Callaway wrote:
>  On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote:
>  > On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
>  > > 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
>  > 
>  > Indeed. Just give the subpackage its own Release tag.
>  
>  I honestly don't care which is the base and which is the subpackage. The
>  biggest issue I see is with arch determination, since they HAVE to be
>  the same between base and subpackage. 
Not, if you separate "building the
rpm" from "releasing the rpm".

Example:
# rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc
i386 glibc-2.3.5-10.src.rpm
i686 glibc-2.3.5-10.src.rpm

Ralf

[Tom Callaway]

On Wed, 2005-06-29 at 18:23 +0200, Ralf Corsepius wrote:

>  > I honestly don't care which is the base and which is the
> subpackage. The
>  > biggest issue I see is with arch determination, since they HAVE to be
>  > the same between base and subpackage.
>  Not, if you separate "building the rpm" from "releasing the rpm".
>  
>  Example:
>  # rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc
>  i386 glibc-2.3.5-10.src.rpm
>  i686 glibc-2.3.5-10.src.rpm 
Thats a very good point, but it will certainly make conditionalizing the
spec file fun. :)

I'm not opposed to that.

Example spec:

# This is defined by the buildsystem, NOT on a per package basis.
#%define kver 2.6.11-1.1369_FC4
%define cleankver %(echo %{kver} | sed s,-,_,g)
%define kernelonlyarches i586 i686 ppc64 sparc64
%define userspacearches i386 ppc sparc 
%define kernelanduserarches ia64 x86_64

Name:		foo
Version:	0.3.6
Release:	1
Summary:	Userspace components for foo
Group:		System Environment/Base
License:	Whatever
URL:		http://www.example.com/foo
Source0:        http://www.example.com/foo/foo-%{version}.tar.bz2
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires:	kernel-module-%{name}
BuildRequires:	kernel-devel-%{_target_cpu} = %{kver}
ExclusiveArch:  %{kernelonlyarches} %{userspacearches} %{kernelanduserarches}

%description
These are userspace libraries and binaries to make the foo module usable.

%package devel
Group:		Development/Libraries
Summary:	Development headers and libraries for foo
Requires:	%{name} = %{version}-%{release}

%description devel
This package contains the include files and static libraries for 
developing applications that use foo.

%package -n kernel-module-%{name}
Group:		System Environment/Base
Version:        %{version}
Release:        %{release}.%{cleankver}
Requires:       kernel-%{_target_cpu} = %{kver}
Provides:       kernel-module

%description -n kernel-module-%{name}
This package contains the foo module compiled for kernel %{kver} on %{_target_cpu}.

%prep
%setup -q

%build
make %{?_smp_mflags} ...

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

%clean
rm -rf $RPM_BUILD_ROOT

%post -n kernel-module-%{name}
[ $1 -eq 1 ] && depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || :

%postun -n kernel-module-%{name}
depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || :

%ifarch %{userspacearches} %{kernelanduserarches}
%files
%defattr(-,root,root,0755)
# docs go here
%doc ...
%{_bindir}/fooexec
%{_libdir}/*.so.*

%files devel
%defattr(-,root,root,0755)
%{_includedir}/*
%{_libdir}/*.a
%{_libdir}/*.so
%endif

%ifarch %{kernelspacearches} %{kernelanduserarches}
%files -n kernel-module-%{name}
%defattr(-,root,root,-)
# This package should NOT have anything besides the module, to avoid file conflicts.
/lib/modules/%{kver}/...
%endif

%changelog
* Gud Fez 74 6395 Foobly Barowitz <foobly(a)barowitz.tld&gt;
- Initial RPM release

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Tom Callaway]

On Wed, 2005-06-29 at 11:55 -0500, Tom 'spot' Callaway wrote:

>  %ifarch %{kernelspacearches} %{kernelanduserarches} 
This line should be:

%ifarch %{kernelonlyarches} %{kernelanduserarches}

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Ville Skyttä]

On Wed, 2005-06-29 at 12:00 -0500, Tom 'spot' Callaway wrote:

>  This line should be:
>  
>  %ifarch %{kernelonlyarches} %{kernelanduserarches} 
With that approach, when a new kernel is released for one of
%{kernelanduserarches}, and only the kernel modules need a rebuild, the
result is that both userspace and the module packages will be built
anyway.  And the userspace package will not have its NEVR changed
compared to the previous one -> something somewhere needs to be able to
just discard it, and NOT push it into the repository.

Also, note that NEVR of -debuginfo is derived from the main package.
So, if the NEVR of the main package does not change between updates (eg.
kernel-update-rebuild-only ones, when the module one is not the "main"
package), the resulting -debuginfo packages will be screwed.  More info
in a semi-related bug report from the FC1 days when I was first bitten
by this: https://bugzilla.redhat.com/113276

There may be ways around these, but I think it'll end up messy.
Splitting the SRPMs would be a much simpler approach, and I don't think
that the maintenance burden of doing that would be untolerable at all.

[Tom Callaway]

On Wed, 2005-06-29 at 21:09 +0300, Ville Skyttä wrote:

>  There may be ways around these, but I think it'll end up messy.
>  Splitting the SRPMs would be a much simpler approach, and I don't think
>  that the maintenance burden of doing that would be untolerable at all. 
Honestly? I agree. Even if it means we end up with two copies of the
full source in two SRPMS.

Unless someone is violently opposed to splitting the SRPMS as policy
(and can come up with a way to resolve the unnecessary userland package
bumps/rebuilds), thats what I'm inclined to adopt.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Matthew Miller]

On Wed, Jun 29, 2005 at 06:55:59PM -0500, Tom 'spot' Callaway wrote:
>  Honestly? I agree. Even if it means we end up with two copies of the
>  full source in two SRPMS.
>  Unless someone is violently opposed to splitting the SRPMS as policy
>  (and can come up with a way to resolve the unnecessary userland package
>  bumps/rebuilds), thats what I'm inclined to adopt. 
I'm fine with this or with the ifarch conditional plan -- either way has its
ugliness. :)

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Matthew Miller]

On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
>  # This is defined by the buildsystem, NOT on a per package basis.
>  #%define kver 2.6.11-1.1369_FC4 
If kver isn't defined, probably the canonical specfile should have a way to
either die in an explanatory way, or else guess at a default somehow.


>  URL:		http://www.example.com/foo
>  Source0:        http://www.example.com/foo/foo-%{version}.tar.bz2
>  BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>  Requires:	kernel-module-%{name} 
*Probably* Requires: kernel-module-%{name} = %{version}, yeah? Maybe not,
but I bet in the general case these need to match.


-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Ville Skyttä]

On Wed, 2005-06-29 at 14:05 -0400, Matthew Miller wrote:
>  On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway
> wrote:
>  > # This is defined by the buildsystem, NOT on a per package basis.
>  > #%define kver 2.6.11-1.1369_FC4
>  
>  If kver isn't defined, probably the canonical specfile should have a way to
>  either die in an explanatory way, or else guess at a default somehow. 
This would implement the latter, which is useful for local rebuilds for
the current running kernel:

    %{!?kver: %define kver %(uname -r)}

[Matthew Miller]

On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote:
>  %define kernelonlyarches i586 i686 ppc64 sparc64
>  %define userspacearches i386 ppc sparc 
>  %define kernelanduserarches ia64 x86_64 
Is there a reason to not just do:

 %define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64
 %define userspacearches i386 ppc sparc ia64 x86_64

Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and
kernel-module-hugemem-%{name} subpackages?

(Or is that kernel-smp-module, to match kernel-smp-devel?)


-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Ville Skyttä]

On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote:

>  Also, how to deal with smp/hugemem? Separate
> kernel-module-smp-%{name} and
>  kernel-module-hugemem-%{name} subpackages?
>  
>  (Or is that kernel-smp-module, to match kernel-smp-devel?) 
None of the above; the variant is included in %{kver}, which is the
output of "uname -r" for the target kernel.

[Matthew Miller]

On Wed, Jun 29, 2005 at 09:49:44PM +0300, Ville Skyttä wrote:
>  > Also, how to deal with smp/hugemem? Separate
> kernel-module-smp-%{name} and
>  > kernel-module-hugemem-%{name} subpackages?
>  > (Or is that kernel-smp-module, to match kernel-smp-devel?)
>  None of the above; the variant is included in %{kver}, which is the
>  output of "uname -r" for the target kernel. 
Oh; duh.

In the case of openafs, that requires some more hackery to figure out if
we're supposed to be giving the options for an smp build. But I suspect this
*way* falls into the category of "openafs is a weird bad example case".


-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.

[Ville Skyttä]

On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote:

>  In the case of openafs, that requires some more hackery to figure out
> if
>  we're supposed to be giving the options for an smp build. 
Doesn't the openafs build figure that out automatically from the kernel
tree you're pointing it at [1]?  Upstream issue?

[1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+

[Jack Neely]

On Wed, Jun 29, 2005 at 10:13:27PM +0300, Ville Skyttä wrote:
>  On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote:
>  
>  > In the case of openafs, that requires some more hackery to figure out if
>  > we're supposed to be giving the options for an smp build.
>  
>  Doesn't the openafs build figure that out automatically from the kernel
>  tree you're pointing it at [1]?  Upstream issue?
>  
>  [1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+
>  
>  
>  
>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging 
OpenAFS sucks...you have to pass the build different options for UP
versus SMP.  

# UP first
%configure --with-afs-sysname=%{sysname}
--with-linux-kernel-headers=%{ksource_dir} --enable-kernel-module
make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_UP=1" MPS=UP only_libafs

# then SMP
%configure --with-afs-sysname=%{sysname}
--with-linux-kernel-headers=%{ksource_dir_smp} --enable-kernel-module
make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_SMP=1" MPS=MP only_libafs

Jack
-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Matthew Miller]

On Wed, Jun 29, 2005 at 03:19:37PM -0400, Jack Neely wrote:
>  > > In the case of openafs, that requires some more hackery to
> figure out if
>  > > we're supposed to be giving the options for an smp build.
>  > Doesn't the openafs build figure that out automatically from the kernel
>  > tree you're pointing it at [1]?  Upstream issue?
>  OpenAFS sucks...you have to pass the build different options for UP
>  versus SMP.   
Capital Letter Upstream Issue. :)

In their defense, they're trying to maintain software with kernel modules
for a dozen different operating systems.

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.

[Tom Callaway]

On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote:
>  On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway
> wrote:
>  > %define kernelonlyarches i586 i686 ppc64 sparc64
>  > %define userspacearches i386 ppc sparc 
>  > %define kernelanduserarches ia64 x86_64
>  
>  Is there a reason to not just do:
>  
>   %define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64
>   %define userspacearches i386 ppc sparc ia64 x86_64 
Not really. :)

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Jack Neely]

Spot,

I like.  :-)

Jack
-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[Ville Skyttä]

On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote:
>  On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skyttä wrote: 
>  > What about archs?  We probably don't want i586 and i686
> userland openafs
>  > stuff, but just i386.  Choices:
>
>  <insert AFS is special here> 
Hm, actually, I don't know a thing about openafs, just used it as an
example.  s/openafs/foo/ in the above.

>  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. 
What's a basearch, the same as in yum/rpmUtils?  If x86_64 or ppc is
one, does your package build modules for it?

[Jack Neely]

>  Actually, no. I'm not going to standardize kernel module
> packaging
>  _UNTIL_ at least yum is fixed.
>  
>  Let me reiterate some points that I have made in the past: 
Good, gets us all back on track.  :-)

>  
>  - I do not plan to overload the %{name} value for kernel module
>  packages. This means that we will NOT be shoving the kernel version in
>  %{name}. Its ugly, it screws up bugzilla, breaks existing packaging
>  guidelines, and is altogether wrong.
>  
>  - Given that, we WILL need to put the kernel version (in some part) in
>  either %{version} or %{release}. Let me explain why:
>   
I can tolerate %{release}

>  On SMP systems, at a bare minimum, there will be two kernels
> installed:
>  
>  kernel-smp-2.6.12-1.1400_FC5
>  kernel-2.6.12-1.1400_FC5
>  
>  If we do not use kernel version in either %{version} or %{release},
>  we'll have no way to generate two packages with unique
>  %{name}-%{version}-%{release} values.
>  
>  We have to assume that each installed kernel will want to have a
>  matching module addon installed for it.
>  
>  I originally proposed (back in March) that we put the kernel version in
>  Release. This is a slightly revised proposal.
>  
>  Name: kernel-module-openafs
>  (where the value in the Name field is the name of the module, prepended
>  with "kernel-module-")
>  Version: 1.1
>  (where the value in the Version field is equivalent to the kernel module
>  version, NOT the kernel version we're building against (in this example,
>  "1", followed by the build revision, in this example ".1") 
So %{version} ends up having the upstream version number and the release
number combined.  I think this is the worst part as its confusing to the
packager.  Why I advocate requiring %{kver}.  However, I did not propose
a solution for a unique NVR for eatch kernel type (smp, xen, etc).

>  Release: %{kver}
>  (Where %{kver} is the kernel we're building against)
>  Requires: kernel-%{_target_cpu} = %{kver}
>  BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
>  
>  %{kver} gets passed by the buildsystem, for each kernel found in the
>  branch for which that package is being built. So, for our example
>  kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp,
>  respectively. FC4 and newer kernels have this value in the provides for
>  "kernel-%{arch}", so it should not be too difficult for the build system
>  to figure out the correct value for %{kver} from the target kernel
>  package.
>  
>  There is no need to use dist tags here, since %{kver} includes the dist
>  name.
>  
>  If a bugfix needs to be made to the package, then the .1 (build
>  revision) is incremented. If a new version of the kernel driver is
>  released, then the first part of the Version is incremented, and the
>  build revision is reset to .1 (if it is not .1).
>  
>  So, after the buildsystem does its thing, we've generated two new binary
>  rpms:
>  
>  kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm
>  kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm
>  
>  Since no previous packages with those n-v-r's exist, yum installs them,
>  just as it would kernels, doing the equivalent of an rpm -i action.
>  
>  Now, on the system we have all four packages installed:
>  
>  kernel-2.6.12-1.1400_FC5
>  kernel-module-openafs-1.1-2.6.12-1.1400_FC5
>  kernel-smp-2.6.12-1.1400_FC5
>  kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp
>  
>  But wait, I've found a bug in kernel-module-openafs. Easy enough to fix,
>  I patch it away, increment my build revision to .2, and we now have
>  these new packages available:
>  
>  kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm
>  kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm
>  
>  But, here yum doesn't know what to do. We can't do a -i, those packages
>  would conflict with the existing kernel-module-openafs packages. We
>  can't do a -U, because then we'd only end up with one
>  kernel-module-openafs package on the system. What we need yum to do is a
>  special operation that does the following (only for kernel-module
>  packages):
>  
>  - Does any kernel-module-openafs package exist on the system with the
>  same %{release}?
>  - If yes, remove it (rpm -e). If no, continue.
>  - Install new package (rpm -i).
>   
I have a patch for yum that does exactly this except it keys off of the
kernel requires.  (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5
require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?)
So in a day or two I could probably have it edited to do the above.

>  After this process, the system has:
>  
>  kernel-2.6.12-1.1400_FC5
>  kernel-module-openafs-1.2-2.6.12-1.1400_FC5
>  kernel-smp-2.6.12-1.1400_FC5
>  kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp
>  
>  Now, if someone is willing and able to write the exception case needed
>  for yum in kernel-module-* packages, then I think we can document the
>  remaining standard bits, duct tape the necessary logic into the
>  buildsystem, and start doing kernel-module-* packages for FC4 and devel.
>   
Since I already have a good bit of the code done...

Spot, the only change I would like in this is to have the build number
not in %{version} but as part of %{release}.  So using your example,

    kernel-module-openafs-1-2.2.6.12-1.1400_FC5

Where the %{release} == build#.%{kver}

This doesn't add or subtract any complexity from the code in Yum.  It
does make the versioning a little easier to grok.

Reading the new mail I got as I wrote this it looks like Matthew and I
agree.  Cool.

Jack

>  ~spot
>  -- 
>  Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
>  Fedora Extras Steering Committee Member (RPM Standards and Practices)
>  Aurora Linux Project Leader: http://auroralinux.org
>  Lemurs, llamas, and sparcs, oh my!
>  
>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging 
-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

[seth vidal]

>  Actually, no. I'm not going to standardize kernel module
> packaging
>  _UNTIL_ at least yum is fixed. 
You realize how backward this is, right? 'Fixing' yum is quite hard
until the kernel module packaging is standardized.

Implementing a single policy is a whole lot easier than coding to meet
every possible policy.

-sv

Kernel modules

[Ignacio Vazquez-Abrams]

I've taken the liberty of starting a page at
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is
intended to be a collection of what we have so far. Judging from what
has been said to date we still don't have an effective scheme for
Version and Release.

-- 
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72

Kernel modules

[Jack Neely]

On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote:
>  I've taken the liberty of starting a page at
>  http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is
>  intended to be a collection of what we have so far. Judging from what
>  has been said to date we still don't have an effective scheme for
>  Version and Release.
>  
>  -- 
>  Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
>  http://fedora.ivazquez.net/
>  
>  gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 
%{version} and %{release} being what they would normally be is what
we've boiled down to.  Neither one contains the kernel VR.  %{version}
is the version of the kernel module ('1.3.84' for kernel-module-openafs)
and %{release} being the build ID ('1'), per normal.

Spot, I think keying off the requires works very well.

Jack


>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging 

-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

Kernel modules

[Tom Callaway]

On Wed, 2005-06-29 at 10:03 -0400, Jack Neely wrote:
>  On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams
> wrote:
>  > I've taken the liberty of starting a page at
>  > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is
>  > intended to be a collection of what we have so far. Judging from what
>  > has been said to date we still don't have an effective scheme for
>  > Version and Release.
>  > 
>  > -- 
>  > Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
>  > http://fedora.ivazquez.net/
>  > 
>  > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
>  
>  %{version} and %{release} being what they would normally be is what
>  we've boiled down to.  Neither one contains the kernel VR.  %{version}
>  is the version of the kernel module ('1.3.84' for kernel-module-openafs)
>  and %{release} being the build ID ('1'), per normal. 
We really need a unique NVR for each package. Using kver in %{release}
is the best way to accomplish this.

Otherwise, we overwrite in the repo.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

Kernel modules

[Jack Neely]

On Wed, Jun 29, 2005 at 10:03:57AM -0400, Jack Neely wrote:
>  On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams
> wrote:
>  > I've taken the liberty of starting a page at
>  > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is
>  > intended to be a collection of what we have so far. Judging from what
>  > has been said to date we still don't have an effective scheme for
>  > Version and Release.
>  > 
>  > -- 
>  > Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net&gt;
>  > http://fedora.ivazquez.net/
>  > 
>  > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
>  
>  %{version} and %{release} being what they would normally be is what
>  we've boiled down to.  Neither one contains the kernel VR.  %{version}
>  is the version of the kernel module ('1.3.84' for kernel-module-openafs)
>  and %{release} being the build ID ('1'), per normal.
>  
>  Spot, I think keying off the requires works very well.
>  
>  Jack
>  
>   
Its obviously too early in the morning.

Ignacio, I must correct myself.  The kernel VR should be appened to the
%{release} tag for the packages.

-- 
Jack Neely <slack(a)quackmaster.net&gt;
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89