Hi Jaroslaw,

> Hi
> 
> > Just to add my 2 cents here. I don't need repo preference. I resolved this
> > issue by disabling all but base repo's, then scripting the packages I want to
> > be notified on (and upgrade to) per repo, then croning updates based on the
> > "--enablerepo=" option in yum.
> 
> Yes , that is an option: but you mostly use it on the
> systems you manage yourself, right ?

Yes.

> At CERN we have about 1500 systems managed by individual
> owners/users .. so we really need a solution which will
> not require all of them writing / editing scripts ..

Are these systems all pretty much identical to the packages that need to be
checked on them? or do the owners/users have root privilege to install/modify
whatever they want on the systems?

I use another product (csync2) to help me manage large nodes of clusters,
where I group "like" systems. My yum scripts can be easily extended to work on
hundreds of nodes using csync2 to synchonise yum check scripts ie. using
csync2, you could easily have multiple "yum.check.atrpms.server1.sh,
yum.check.atrpms.server2.sh" scripts distributed to hundreds of nodes, managed
from one main server and distributed automatically to groups of nodes, while
those scripts are cron'ed on each of the nodes to check a central repo/mirror.

As an admin, I like the control this gives me, as I can manage everything from
a central server.

> So far we were working with apt using repository
> preference and ability to 'pin' (=lock) package versions.
> (plus ability of LUA scripting for kernel modules upgrades)
> 
> For me, it looks like combination of yum protectbase,
> versionlock and kernel-module plugins
> (plus few more yum-utils like build-dep and sourcedownload)
> would allow us to achieve similar result with yum.

The thing I don't like about automatic things is that implementations on
servers become too messy over time. It becomes very hard to keep track of what
packages are installed and especially keeping track of the dependencies those
packages installed.

The administrative overhead may be a little more, but in the long run I
believe it reduces problems which occur on systems after they've been in the
wild for some years.

> [FYI: As apt for rpm is not being developped
> anymore for future versions of Scientific Linux CERN
> we are looking at replacing our default update mechanism
> by a yum based one.]
> 
> Regards
> 
> Jarek
> 
> PS: Maybe you could contribute your scripts to SL ?

Yeah, I'm happy to do this. About a month and a half ago I was speaking with
Troy about it, as I have implementations for Fedora Core releases and SL4
releases.

The Fedora Core scripts are all in-house and specific to those releases (so
not much help to the SL community), while the SL scripts extend Troy's scripts
to allow an admin to manage "repo.package" files which are called from the
main check script. So the end result is an email to the admin of all the
packages updated per checked repo, in one nicely formatted email. The admin
then has the choice whether to update them or not.

The last we spoke about this I told Troy I'd clean up the scripts a little
more then send them all to him (I need to make them more generic for the
public - like a template file - and not specific to my setup for example). But
I've been tied up with cluster work since then, which should be finished by
next week. After that, I'll relook at the scripts, clean them up (for public
release) and send them to Troy. From there, it's up to him what he does with
them :)

Michael.