On Wed, Jan 17, 2007 at 01:13:26PM -0700, Tim Rightnour wrote:
> System is cut up into basically syspkgs.  Each one has a version number, like
> 5.3.0.1.  (5.3.0 AIX, rev 1 of this pkg).  Each pkg has a state, COMMITTED or
> APPLIED.  When you install a new pkg, you APPLY it.  This backs up the old one,
> and lays down the new one.  When you COMMIT, you delete the old one.  If you
> want to back out, you REJECT the new one, and it puts the old one back.

We don't yet have syspkg, but I think we can *easily* get a very
similiar functionality with the existing tools.

What I want is a system of three parts:
(a) A machine parseable list of all vulnerabilities for a given release.
(b) A list of all updates for a release with containing:
  - references to SAs as applicable
  - references to required updates
  - references to obsoleted updates
  - references to conflicting updates
  - a tarball with the actual update

  The first three should be obvious, the latter is handy for hot-fixes
  and other special cases.
(c) The management component which provide the following:
  - a list of already applied and refused updates
  - a check for new updates
  - applying an update
  - optional backups of the files to allow reverting an update

I prefer full file updates as it is IMO a lot more reliable and easier.
The bandwidth argument is IMO weak as long as it is easy enough to
choose a mirror or set one up.

Interesting questions are validation of updates and the lists. An
OpenSSL cert would be an option, optional hooks for PGP/GPG another.

Joerg