On Tue, Jan 23, 2007 at 03:58:51PM -0600, Troy Dawson wrote:
> Axel Thimm wrote:
> >On Tue, Jan 23, 2007 at 12:02:24PM -0600, Troy Dawson wrote:
> >>I have one question about the stub package.
> >>If the stub has
> >>  Requires: foo-kmdl-`uname -r`
> >>What happens when you update your kernel when you already have the stub 
> >>installed?
> >>`uname -r` = 2.6.19-10.0.2
> >>yum update brings in kernel 2.6.19-10.0.3
> >>Unless you have a plugin, then it's not going to get the new kdml
> >>Or am I missing something?
> >
> >The mechanism works as follows, there are three packages or better
> >said package types
> >
> >o main package (userland): "foo-EVR"
> >  depends on the virtual dependency foo-kmdl-EVR
> >  (note: no <uname -r> part in this dependency)
> >o kmdls (kernel component): "foo-kmdl-`uname -r`-EVR"
> >  provides virtual dependency foo-kmdl-EVR
> >  requires foo-kmdl-4-<kernel series and flavour>
> >o kmdl stub: "foo-kmdl-4-<kernel series and flavour>-KEVR"
> >  (note: no EVR part)
> >  requires virtual dependency foo-kmdl-`uname -r latest`-EVR
> >
> >Notes:
> >- There is an intended circular dependency between kmdl and
> >  kmdl-stubs. That way a user installing a kmdl will automatically get
> >  the automatic updates.
> >- The userland requires just any kmdl for any kernel
> >- kernel series are for example:
> >  - vendor kernel (+ flavours)
> >  - kernel-suspend2 (+ flavours)
> >  - kernel-desktop (+ flavours)
> >  - kernel-centosplus (+ flavours)
> >  - kernel-SL16k (+ flavours)
> >- Different kernel series may have completely different versioning,
> >  therefore they need their own kmdl stub
> >- A kernel upgrade will induce an upgrade of the kmdl stub, which in
> >  turn will pull in the required kmdl.
> >
> >Example:
> >
> >o Installed:
> >  kernel-xen-2.6.20-1
> >  foo-1.0-2
> >  foo-kmdl-4-kernel-xen-2.6.20-1
> >  foo-kmdl-2.6.20xen-1-1.0-2
> >
> >o kernel upgrade: Release becomes 1.1
> >
> >  new packages in the repo (note: each package has several flavour
> >  siblings):
> >  a) kernel-xen-2.6.20-1.1
> >  b) foo-kmdl-4-kernel-xen-2.6.20-1.1
> >  c) foo-kmdl-2.6.20xen-1.1-1.0-2
> >
> >  a) get coinstalled by conventional kernel "upgrading"
> >  b) gets truly upgraded due to KEVR path
> >  c) gets coinstalled as a dependency of b)
> >
> >o foo upgrade: EVR becomes 2.0-1
> >
> >  new packages in the repo:
> >  a) foo-2.0-1
> >  b) foo-kmdl-2.6.20xen-1.1-2.0-1
> >
> >  Both get upgraded by conventional EVR mechanics
> >
> >So there is no plugin required. :)
> 
> Wow
> That takes a couple readings to get my head around it, but I believe you 
> are right.
> That would definatly cut down on the spec file stuff, and the plugin 
> necessity.

Indeed, the specfile stuff is similar to what ATrpms has today (as
said, kmdl2 has some optimizations, e.g. no %package, %post, %postun
for the kmdl package), and the stub part can be implemented into the
macros, e.g. %kmdl defines both the kmdl and kmdl-stub %packages.

> One questions/comment
> What is the 4 for in "foo-kmdl-4-<kernel series and flavour>-KEVR" ?

4 = "for", e.g. for kernel series/flavour such and such.

> That just seems to add one more number in a name that is already full of 
> numbers.
> It looks like we can replace "kmdl-4" with anything as long as it's 
> logical.  I was thinking something like "kmdl-stub" or even "stub"

I'd love a better name than "kmdl-4". The name needs to contain "foo",
the kernel series, kernel flavour and kernel EVR (KEVR). And it
shouldn't be confused with the plain kmdls. Also kernel series,
flavour and KEVR should best be naturally aligned as found in the
matching kernel naming/versioning

Maybe something like

foo-autokmdl-kernel-xen-2.6.20-1.1

E.g. "foo" + "-autokmdl-" + <full name of kernel series/flavour>?

It emphasizes the auto-upgrading/coinstalling nature of this
package.

I wouldn't like the name stub, because while it isn't anything more
than a stub, a stub always implies there is a full version somewhere
(perhaps in the future), which is not the case here (for example for
ATrpms build system in chroots I use "kernel stubs" that are empty
packages simulating the kernel package's presence.)
-- 
Axel.Thimm at ATrpms.net