apt-class WAS: fai next level

[Geert Stappers]

At 11:44 +0100 11/14/01, Diane Trout wrote:
>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.
Oops.
Thank for the pointer.

>
>> >
>> >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.
>

This looks like FAI code.
The different is that FAI uses NFS to get the class info.

>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?
It is up to you.
IMHO Python and SWIG as your friend to make C++

>
>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?

You are going way beyond FAI.  That is good!!!

Please talk to the apt team ( deity team )

>
>diane


Geert