Kernel module packages (was - Re: Pre-Review: Asterisk)

[Ville Skyttä]

On Sat, 2005-04-02 at 16:56 -0600, Tom 'spot' Callaway wrote:

> As I said before, we can skirt this problem if we overload the %{name}
> and put the kernel version there. However, this means that in CVS, we'd
> have separate branches for every possible kernel version, bugzilla would
> have entries for every possible kernel version. Its bad, and we
> shouldn't do it.

Bad, yes, but I guess the separate Bugzilla and CVS entries would not be
a "must", but rather the current state of affairs in how various scripts
work.  By the way, an instance of this %{name} abuse is kind of already
the kernel, kernel-smp, kernel-xen0, kernel-xenU, etc naming scheme.
Not exactly the same, but similar.  Anyway, I'm not advocating the
version-in-name abuse in module packages, if something better, or
equivalent but less ugly is found.

> We need to teach rpm to perform the following transaction (ignoring
> normal dependency checks):
> 
> - package kernel-module-foo-2.6.10_2-1, kernel-module-foo-2.6.10_2smp-1,
> and kernel-module-foo-2.6.10_3-1 are installed (-i will permit this).
> - user asks for packages kernel-module-foo-2.6.10_2-2,
> kernel-module-foo-2.6.10_2smp-2, and kernel-module-foo-2.6.10_3-2 to be
> installed.
> - rpm looks for existing packages which match %{name}-%{version} for
> each of these pending update packages.
>  - if found, then compare %{release} with that existing  
>    %{name}-%{version} package
>   - if %{release} of pending update is greater than existing, then 
>     upgrade ONLY that existing package with same %{name}-%{update}
>   - else, if %{release} of pending update is same as existing, then 
>     compare epoch
>     - if epoch of pending update is higher, then upgrade ONLY that 
>       existing package with same %{name}-%{update}
>   - else, if %{release} of pending update is lower than existing, then 
>     exit with error.
>  - else, if not found, perform standard -i operation on pending update 
>    package.
> 
> Does that make it more clear? :)

Yep, but perhaps also unnecessarily hairy; making it possible to shuffle
the weight of E, V, and R in rpm version comparisons does not sound good
for one's health (the "compare Release before Epoch" case in the above).

Some thinking aloud follows, caveat emptor...

Could it be simplified/generalized into let's say "upgrade scopes"?
Currently, the only, traditional upgrade scope is a package's N.  Other
valid scopes could be NE, and NEV.  Maybe add A if/where necessary or
useful.  These scopes would be treated like:
- N: like it has always been.  Compare EVR of packages with name N to 
  decide whether an upgrade is available etc.
- NE: compare VR of all packages having the same NE.
- NEV: compare R only of all packages having the same NEV.

Not sure if/how this should/would affect versioned Obsoletes, Conflicts,
and/or Provides.

Anyway, in the above kernel module naming+versioning scheme, setting the
upgrade scope of these module packages to NEV would probably produce the
wanted results.

But I'm not sure if this is the right path.  We want to restrict the
version comparisons so that only module packages built for a specific
kernel get compared for upgradeability, otherwise installed in parallel
as if they had different %{name}s.  Or more generally, make rpm aware of
what the packages are built _for_, instead of coming up with new wicked
context-free NEVR comparison schemes.  So, what about a "For:" tag.

  For: foo = bar

...or Requires(parent): or something even better.  This would be
equivalent to "Requires: foo = bar", except that in addition, rpm and
depsolvers could use "foo = bar" to group the "child" packages for the
upgrade or install decision.  Older rpm and depsolver implementations
would just ignore the extra info and treat these as normal Requires.