apt-class WAS: fai next level

[Diane Trout]

Geert Stappers <Geert.Stappers at xs4all.nl> writes:
> 
> Do we already have the syntax definition of the package_files?
> Is FAI aware of unstalling packages?

Yes, there is a brief definition of the syntax in section 6.8 of the
FAI manual.

> >
> >If this "apt-daemon" existed it would be rather easy to update systems
> A daemon.
> Sounds like "push". http://www.infrastructures.org says us "pull"

Actually it sounds more like a bad name.

How about "apt-class"? 

In my mind the program is designed to be run on client machines, it
receives a class list from some external source (in my case from
cfengine). From that list it determines what packages should be
installed, removed, and perhaps held. 

> Tell us more.

Looking into the problem slightly further, it looks like the easiest
solution is to write out a selections file that could be installed via
dpkg --set-selections and then use a apt-get dselect-upgrade to
actually initiate the upgrade.

It should be pretty easy to parse the current FAI package_config file
format. Though I'm not really sure what the difference between a
"PACKAGE taskinst" and just specifying task-* as a package is.

To take advantage of the hold state, I'd need to add a "PACKAGE hold"
to the current package_config file format. A held package won't
be upgraded without being removed from the held state.

As far as I can tell the consequences of the design are:

* A package can have the following desired install states: install, hold,
  deinstall, purge, and unknown. 
* To prevent a package from being automatically upgraded it would have
  to be placed in the "held" state, things in the unknown or install
  states get upgraded.
* apt-get dselect-upgrade can deal with constructing the dependency list.
* apt-get dselect-upgrade ignores package names that don't exist in
  the available database. (solving the original problem with apt-get)
* there really isn't any error handling of packages not being in the
  archive. 

I was thinking of writing it in either C++ or Python, any preferences?

Also what can be done about packages that are reading/writing to the
console? The best solution I thought of is to provide a timer that
can either kill the install or send email after some delay. However for
the email to be useful the program would need to provide a way for the
sysadmin to log into the machine and connect to the apt-get session.

What do people think of the rough outline of the proposed program?

diane