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.
