Getting people into Linux

[Les Mikesell]

On Sat, 2007-01-06 at 01:16 +1030, Tim wrote:
> >> Isn't Anaconda supposed to be able to provide for that sort of thing?
> >> You'd still use the same repos, but just a different installation
> >> script.
> 
> > Yes, anconda does probe and understand the hardware differences
> > during an install, but it isn't involved with subsequent updates.
> > Kickstart can do an initial install of a matching set of packages
> > on different hardware, but then yum just updates the currently
> > installed packages. What I'd like to see is the ability to put
> > a large range of packages and package versions in the same
> > repositories and have an ongoing ability to track package and
> > package version changes to match a chosen master copy.  For
> > example, if the administrator of the master machine defers a
> > kernel update, pulls a few newer packages from the rawhide
> > repository, and installs postfix as an alternative to sendmail,
> > I'd like the tracking machines to offer to make the corresponding
> > changes on their next update run. 
> 
> For a follow-the-leader thing, wouldn't you be better off if the leader
> was to make a list of things to be pushed onto the followers, manually,
> rather than them just copying it blindly?  Else one little experiment
> would flow onto everything else.

Yes, I was leaving a few details for the implementation.  I'd expect
the master admin to do some sort of 'bless' command after his
changes to make them available for propagation - or at least for
the master machine to still be operational after the changes are
completed there (and a reboot happens for kernel updates). 

> I could imagine a nightly cron job on clients that looked for a list on
> the server of things to be done with the yum equivelent of rpm -Uvh.
> With some sort of serial number (ala DNS records), so a client doesn't
> try to do it twice.

I picture it as a slightly more intelligent version of a yum update
where revision levels are stated explicitly and a repeat would not
make any changes.  It could even permit a mix of explicit revision
control on certain packages managed at the master and local additions
that do a yum-style "track the latest in the repository" although
then you'd have to handle dependency conflicts manually.  You can
get somewhere close to this with some invocation of 'rpm -qa ...'
followed by telling yum to install that list of packages on another
machine for the initial setup, but you can't track changes that
way.

-- 
  Les Mikesell
   lesmikesell at gmail.com