SCIENTIFIC-LINUX-DEVEL Archives

January 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Tue, 23 Jan 2007 15:58:51 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (91 lines)
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.

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

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________

ATOM RSS1 RSS2