Handling Updates...

[Phil Meyer]

semi linux wrote:
> I'm looking at moving to F7 for our next generation HW.  As an
> investigation into the running of F7, I installed it on our old HW to
> check it's functionality and prep for the changes.
>
> Right away I got "BUG: warning at
> kernel/softirq.c:138/local_bh_enable() (Not tainted)".  This bug has
> been reported and fixed
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982)...
>
> The end result is that I have to update the kernel.
>
> The question :: If I'm going to update, how can I freeze on one
> particular update (so I ship the same thing today as I do in 1 year)?
>
> We use kickstart already, so updates can be scripted easily enough but
> I would imagine that Glibc/gcc and other updates should occur at the
> same time as the kernel - What's the proper way to stop this from
> being a moving target?  Do I just download everything today and hope
> it's a good freeze point while scripting it into our kickstart files?
>
> Anyone here solved this problem before?
>
> - G.
>
>   

Can do.

You may wish to roll your own.  This is what we do:

1. Test Fedora until we hit a reasonably stable platform.
2. Freeze the local repositories.
3. Use pungi to roll a release of Fedora containing all of our released 
software.
4. Install from that release (we put our custom kickstarts on the 
release) for the next iteration of that service.
5. Unfreeze the repositories and continue testing.

The next time a major release of our product occurs, we re-roll.

This way we stay fairly current, have the best stuff available at the 
time of release, and have reasonable quality control.

My specific part in this is the testing and rolling out of the platform.
I also manage the development platform to make sure its reasonably 
current and stable.

My particular fancy is to hand the field tech a USB thumb drive with the 
latest OS/Application mix, and they install from that without any 
support or assist from me.  Its great.  But a DVD based release is also 
a result of the roll out.

So basically I roll a release every kernel release or major component 
release (postfix, httpd, etc) and test test test.

So whenever they do a version release of our software, I simply drop 
their package into my local repository, roll a release (from a 
previously tested package set) and test it.  If all is well I write it 
to the thumb drive and send it to the field techs.

We use a local repository of the Fedora release, so that it can be 
'frozen' at any given time while the new release is produced.

Hope this makes sense.

Good Luck!