I volunteer

[Jack Neely]

On Thu, Sep 25, 2003 at 04:51:21PM -0400, seth vidal wrote:
> On Thu, 2003-09-25 at 16:46, Bill Nottingham wrote:
> > seth vidal (skvidal at phy.duke.edu) said: 
> > > the biggest problem to work around has todo with kernel updates and
> > > openafs version updates.
> > > 
> > > the openafs kernel modules are built to a specific kernel version and
> > > therefore must be install-only -not hard.
> > 
> > Current up2date will do the install-not-upgrade dance for any
> > package that 'Provides: kernel-modules' - I'm guessing similar
> > capabilities could be added to apt and yum fairly quickly, and
> > such packages ported to provide that...
> 
> yum has an installonlypkgs config that can be set but it is not handled
> automagically - I'll have to do that.
> 
> still doesn't get around the problem of the modules needing a specific
> version of the openafs client software.
> 
> -sv
> 

So I have a question about the package naming guidelines.

I'm using yum.

A common thing is to push out a new kernel update for security reason 42
and in the same push push out a complete set of openafs-* packages.  The
new openafs-kernel packages work with the new kernel and require that
kernel version.

With the Fedora naming scheme the openafs-kernel packages turn into
kernel-module-openafs-2.4.20-19.9 and do not require a kernel version.

So unless there's another requires somewhere to require the provided
kernel-module-openafs = %{epoch}:%{version}-%{release} how does the new
OpenAFS package get upgraded?

I guess in my case I can have openafs-client do the above require.
(Right now it only requires %{version}.)

What if I was shipping something that was just a kernel module and not
other accompanying packages?

Jack Neely


-- 
Jack Neely <slack at 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