[Fedora-packaging] Re: DKMS into Fedora Extras

Chuck R. Anderson cra at WPI.EDU
Tue Feb 22 00:47:52 UTC 2005


On Mon, Feb 21, 2005 at 02:48:44PM -0600, Tom 'spot' Callaway wrote:
> >I think that adding the kernel version-release to the package name of
> >the kernel-module-foo packages is a bad idea.  I think it would be
> >better to have the kernel-module-foo actual version-release tag be the
> >same as the corresponding kernel version-release tag.  Then you could
> >just parallel install the kernel-module-foo packages in the same way
> >that the kernel is parallel installed.
> 
> Give me an example for both cases (the case you don't like and the case
> that you do)?

I don't like this:

Name: kernel-module-unionfs-2.6.10-3_FC3
Version: 1.0.9
Release: 15

because it requires special magic in the depsolver to pull in
specially named packages when kernels get installed/erased.  It is a
bad idea to start parsing out parts of a package name.  I would also
think that it would require the user to do things like "yum install
kernel-module-unionfs-2.6.10-3_FC3" which is ugly.

I was contemplating this:

Name: kernel-module-unionfs
Version: 2.6.10
Release: 3_FC3

but that causes the problem below:

> >Of course, then we have a problem if you want to update a kernel 
> >module without updating the corresponding kernel package.  Would this 
> >happen that often?
> 
> Assume it will. :)

So, how about we completely divorce the module version number from the
kernel version number, since you basically want to be able to update,
build, and evolve them separately, and the "version" of an external
kernel module doesn't really have any relation to a kernel
version-release anyway:

Name: kernel-module-unionfs
Version: 1.0.9
Release: 15

But you probably still want to stick some info about which kernel each
build of the kernel-module package is built against (purely cosmetic,
NOT to be used programmatically by depsolvers).  Usually the Release:
field is used for this purpose.  This also gets us unique EVR's which
IIRC we need for parallel-installable packages:

Name: kernel-module-unionfs
Version: 1.0.9
Release: 2.6.10_3_FC3.15

The depsolvers would rely solely on Provides/Requires deps:

Name: kernel-module-unionfs
Version: 1.0.9
Release: 2.6.10_3_FC3.15
Requires: kernel = 2.6.10-3_FC3

exactarch's would have to be matched, of course.  smp is fine, because
kernel-smp provides kernel-smp:

Name: kernel-module-smp-unionfs
Version: 1.0.9
Release: 2.6.10_3_FC3.15
Requires: kernel-smp = 2.6.10-3_FC3

So now lets go through the cases:

> Case 1: kernel-2.6.10-3_FC3 installed. User runs: "yum install
> kernel-module-unionfs" to get the unionfs module RPM for
> kernel-2.6.10-3_FC3.

yum notices that kernel-module-unionfs is multiple-installable.  It
finds that it can only satisfy the deps with
kernel-module-unionfs-1.0.9-2.6.10-3_FC3.  Since kernel is i686, it
installs kernel-module-unionfs-1.0.9-2.6.10-3_FC3.i686.

> Case 2: kernel-2.6.10-3_FC3, kernel-2.6.10-4_FC3, and
> kernel-2.6.10-5_FC3 are installed. User runs: "yum install
> kernel-module-unionfs" to get the unionfs module RPM for all
> installed kernels. (I think it is safe to assume that if a user has
> multiple kernels installed that they would like an addon kernel
> module to be installed for all of them)

yum notices that kernel-module-unionfs is multiple-installable.  It
finds all the matching kernel-module-unionfs-* packages whose deps can
be satisfied with the existing installed packages *that are
multiple-installable*.  If there are multiple install candidates
within each Provides: N = E:V-R of installed multiple-installable
packages, it picks the one with the highest EVR (to handle updated
kernel-module-foo pacakges).

If the mechanism for signaling multiple-installable is the same as the
current installonlypkgs= (would be advantageous to use pre-existing
config statements wherever possible IMO), then one might think that
this would make "yum install kernel" install all available kernels,
too.  If this is undesired, you can make yum require that there exist
at least one Require: on another multiple-install package in order to
invoke the special muliple-install behavior.  Otherwise, standard
install behavior is used.

> Case 3: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1
> are installed. User runs: "yum update kernel-module-unionfs" (either
> implicitly, or as part of a generic update all), and
> kernel-module-unionfs-2.6.10_3_FC3-2 exists in Fedora Extras.

To clarify for my naming convention, if these are installed:

kernel-2.6.10-3_FC3
kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15

And this exists in Extras:

kernel-module-unionfs-1.0.9-2.6.10_3_FC3.16
 (Requires: kernel = 2.6.10-3_FC3)

yum notices that there is more than candidate that satisfies the dep
kernel-module-unionfs Requires kernel = 2.6.10-3_FC3, where both
"kernel-module-unionfs" and "kernel" are marked multiple-installable. 
It picks the highest EVR on the repo, in this case
1.0.9-2.6.10_3_FC3.16.

> Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1
> are installed. User runs: "yum update kernel" (either implicitly, or
> as part of a generic update all), and both kernel-2.6.10-4_FC3
> kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras.

If these are installed:

kernel-2.6.10-3_FC3
kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15

And these exist in Extras:

kernel-2.6.10-4_FC3
kernel-module-unionfs-1.0.9-2.6.10_4_FC3.15
 (Requires: kernel = 2.6.10-4_FC3)

yum notices that there are newer packages available that are
multiple-installable.  The first one, kernel, doesn't have any
Requires: on any other multiple-installable packages, so it just
installs (not updates) it as usual.  The second one,
kernel-module-unionfs, does have a Requires: on a multiple-installable
package (kernel).  yum proceeds as in Case 1 or Case 3.

How does this sound?  I think this should just "do the right thing"
without any more configuration than the existing "installonlypkgs=" we
have today.




More information about the Fedora-packaging mailing list