On Wed, Nov 14, 2001 at 02:44:30AM -0800, Diane Trout wrote: > How about "apt-class"?
Unless the tool will rely upon apt and dpkg alone, I would stay away from the apt-\(.*\) namespace. Currently, the classes that FAI uses are defined by two things: scripts and lists. The scope of a class is far greater than the packages that FAI installs; another reason to stay away from the apt-\(.*\) namespace. > 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. Tom has listed a softupdate script that's in the workings, and it has promise. FAI is actually a very client-oriented installation scheme. The BOOTP/DHCP client mounts the FAI root directory and share directories over NFS, then executes rcS_fai. Classes are defined, tasks are performed. It's all very client-centric. The next step is really to clean up FAI as it is so that more of the tasks can be re-entrant. In some cases, this may be as simple as keeping a state file in ${target}/var/state/fai for each task. e.g. task_install > 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. I believe FAI already uses this. I recall seeing such calls in the rcS.log file. I'll have to look at it closer, but I'm still of the opinion that > 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. taskinst??? Do you mean "install"? Just to bring you up to date on the Debian "tasks", they're rethinking the whole "task" structure. If you haven't noticed already, but the "task-\(.*\)" packages have slowly been disappearing from the Debian tree. A perfect example is the task-devel-common file that I had to remove from our FAI package_config/DEVEL list. > 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. That would be nice. > 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) I'm skeptical about this one. I recall the apt-get dselect-upgrades failing on me as well as that standard "upgrade" target. Either a package pre-verfication run has to be made, or we need to chunk out the packages into smaller bites. That way a failure won't be a total failure. If apt could be altered to do the "best it can" with a package install list, that would be idea. > * there really isn't any error handling of packages not being in the > archive. Exactly. One of those reasons I think a state-based install would benefit us greatly. > I was thinking of writing it in either C++ or Python, any preferences? Bash, unless you're willing to commit us to installing Python on our systems as well, or porting your C++ tools to a number of architectures. Currently, we can't get a working install without Perl. This is unfortunate. I know there are developers working on tools to make Python a necessity as well. Again, unfortunate. > 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. debconf already addresses this issue with it's non-interactive target. If you would like to help out in this regard, start uploading NMU's to existing packages that you stumble across. There are other ways to get around this as well: expect scripts, mkdivert, FAI hook scripts. The really unfortunate/fortunate thing about FAI is that you're forced to learn a lot about your systems and the tools you use to manage them in order to make the install work. Tom has given us a great head-start. We just need to help him clean it up a bit. It'll always be a custom job to install FAI. -- Chad C. Walstrom <[EMAIL PROTECTED]> http://www.ima.umn.edu Assistant Systems Manager, IMA Phone: 612-624-4353 Fax: 612-626-7370