apt-class WAS: fai next level

[Thomas Lange]

>>>>> On 14 Nov 2001 02:44:30 -0800, Diane Trout <diane at caltech.edu> said:

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

Why using classes from cfengine ? If a machine was installed using
FAI, it already belongs to FAI classes which are saved in
/var/log/fai/localhost/install/FAI_CLASSES. OK, cfengine can add more
classes, but are they really needed ? Has the list of classes to be
fixed after the first installation or is it a good idea to add/change
classes for a running system? Think about theses questions.

    > 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.
You can use apt-get --simulate to get all dependencies and convert
this output to the set-selections format if really needed. Sounds like
easy work for Perl.

    > It should be pretty easy to parse the current FAI package_config
    > file format.
Using Perl, you will only nedd a few lines.


    > file format. Though I'm not really sure what the difference
    > between a "PACKAGE taskinst" and just specifying task-* as a
    > package is.
task-* packages are removed in woody. Therefore we have to use tasksel
and "PACKAGE taskinst" for installing new task packages.

    > 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
Do you know, how to set a package on hold ? Tell me, and I will
implement it into install_packages.

    > * there really isn't any error handling of packages not being in the
    >   archive.
Send a bug report to the apt team.

    > I was thinking of writing it in either C++ or Python, any
    > preferences?
Why not a shell or Perl script ?  AFAIK, Phython is not in the base of
Debian. A C++ program will not be architecture independent. I would
prefer Perl, since I can debug it and I can help you improving this
script ;-) And speed isn't the problem during installation.

    > Also what can be done about packages that are reading/writing to
    > the console? 
This is a bug of these packages. All packages should use debconf and
then we can say "DEBIAN_FRONTEND=Noninteractive". That's all.

-- 
 Thomas