Hello John,


On Mon, 2008-09-01 at 20:44 +0100, Jon Peatfield wrote:
> On Mon, 1 Sep 2008, Jean-Paul Chaput wrote:

> We normally just stick something on the end of %release ie see the comment 
> in the kernel specfile:
> 
> # Polite request for people who spin their own kernel rpms:
> # please modify the "buildid" define in a way that identifies
> # that the kernel isn't the stock distribution kernel, for example,
> # by setting the define to ".local" or ".bz123456"
> #
> #% define buildid
> 
> setting something like:
> 
> %define buildid .lockdpatch1
> 
> means that the release will have that stuck on the end and so count as 
> 'newer' than any current version but will be older than the next real 
> release from upstream (which hopefully contains those fixes).
> 
> > So I made a "variant", that is another kernel but with the
> > same version, so it do get in the way of the updates.
> > Besides, it allows to revert to the up-to-date stock kernel
> > in case of unexpected problem.
> 
> Obviously during testing one may want to back off but having multiple 
> versions installed allows for temporary backoff and simply removing the 
> newer version will make the previous newest the default.
> 
> Havibng it count as 'newer' helps when you want to add it to a local repo 
> and push it to hundereds of boxes.  We will only add a locally patched 
> kernel to our (standard) repos once we have tested the new kernel enough 
> so we are pretty confident that any extra patches havn't broken anything 
> (or at least nothing we care about).


I'm well aware of the build id trick, but in my understanding (I may be
wrong) it has been created to distinguish between a stock kernel and
an home made one. That it is considered as "newer" is a side effect.
So regarding the name distinction, the variant is OK.
I take from your response that your may insert newer kernels into your
local copies of the standard SL repositories. Making a variant allows
you to have the patched kernel existing alongside the pristine one and
not shadowing it. So you can put it in the repository, do your tests
using yum to install/deinstall then keeping it or throwing it.
In this regard, I think the variant is best.

In truth, I've come to the variant solution for a different reason :
to provides my users with features disabled by TUV, but keeping
the standard kernel along. But it has also proven useful for
including patches. Another requirement is that the various kernels
have to cohabit in the same repository. For I use only one repository 
for network install/update in which I automatically merges all
bugfixes/updates (it also allows to provides my users distribution
DVD on demand with all updates already included, enabling offline
installations).


> > I've made this kernel avalaible because I took me little time
> > (automated procedure...) and some people seemed to be stuck
> > by this bug.
> 
> Indeed but ideally people may want a fixed kernel for all the existing 
> varieties/versions - since they may be using any of them...

 I hope they do. But in the meantime, it could be useful.


 Best Regards,

-- 

      .-.           J e a n - P a u l   C h a p u t
      /v\     A d m i n i s t r a t e u r   S y s t e m e
    /(___)\                       |
     ^^ ^^                        |-- e-mail : [log in to unmask]
                                  `-- Tel    : (33) 01.44.27.53.99 [prof.]
                                                    06.66.25.35.55 [port.]
                                                    01.47.46.01.31 [pers.]

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    A S I M   Architecture des Systemes Integres et Micro-electronique