Thomas Lange <[EMAIL PROTECTED]> 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