apt-class WAS: fai next level

[Diane Trout]

Thomas Lange <lange at informatik.uni-koeln.de> writes:

> 
> Why using classes from cfengine ? If a machine was installed using

Because in my environment there are machines that aren't installed
with FAI. For example most of my coworkers have laptops that they
installed, it would be nice to provide a method for them to use parts
of the configuration system I implemented using cvsup and cfengine. If
they wanted to add the java development environemtn they could just
add the that to their config file and have the same packages that are
installed on our workstations be installed on their systems.

Also I forgot to mention that I wanted my program to also be able
to parse FAI classes. The idea being that it should be useful to FAI
as well a being able to be useful on its own.

Also at the time I was thinking of this package I didn't know that FAI
could do a soft upgrades. Is that convered in the documentation
anywhere?

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

That's a good point. Do you think the following a reasonable
justificiation on why someone might want to change the classes on a
running system?

Being able to add or remove a class to a running system would allow
moving or adding a services to a machine like http, database, dns, 
mail, nfs, samba server or a new printer.

However for it to be useful you also need to have infrastructure that
can make sure the proper config and data files are available. I have
setup tools that can make sure the right version of a config file is
present after changing the class membership of a machine.  Making sure
large data files are present would be harder. So moving a database or
home directories probably couldn't be done automatically, but adding
an nfs share to share a binary directory, making a machine a list mail
server, or a backup dns server might be reasonable reasons to change
classes.

> You can use apt-get --simulate to get all dependencies and convert
> this output to the set-selections format if really needed. 

Even better there's apt-cache depends which can give you per package
lists of dependencies (even the suggests and replaces fields as
well). Or theres apt-cache showpkg which can provide the reverse depeneds.

> Sounds like easy work for Perl.

It would be easy work for python too. But since I was thinking of
trying to be useful for FAI, and since I have asthetic issues with
perl, and didn't want to pull in another interpreter, C++ seemed the
best remaining language. Actually since C++'s string class is
reasonable, it shouldn't be that miserable to write such a program in
C++.

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

I don't think python is in the debian base either, and I don't know
perl. I'm not sure if a shell script is terribly robust. 

I did imagine my program being run periodically from cron (via
cfengine), not just during an install, so performance might be
slightly more of an issue.

> This is a bug of these packages. All packages should use debconf and
> then we can say "DEBIAN_FRONTEND=Noninteractive". That's all.

Okay, I hadn't recently read the debian policy manual. And I had
looked at the debconf compliance graphs which showed that only a few
percent of the packages were using debconf. So was assuming that
full debconf compliance was quite some distance in the future.

diane