This is very much like I have already implemented, the 'synchronisation' takes place in the machine logoff script, but could be called from anywhere, and a separate log of files that should be present is kept on the local machine - only 'atoms' - to use your terminology - that have not already been called are installed at next boot up.
There is a full explanation of what I have done under a previous thread - it got a bit off topic so it is called 'Requesting "mapdrive.pl" from Scott Card' - there are some limitations, uninstall is not supported unless you script it like a new install, and there is not enough recovery from faults, if a script fails or is terminated the auto logon stays in place, but it does handle multiple setup profiles by using different definition files, & supports a crude type of versioning. Take a look & see if it going in the direction you are thinking of Regards Kevin Lawry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Patrick J. LoPresti Sent: 14 June 2003 17:42 To: [EMAIL PROTECTED] Subject: [Unattended] Package management, bigger idea "Patrick J. LoPresti" <[EMAIL PROTECTED]> writes: > Modify install.pl to list all of the files under z:\bundles, and let > you select any number of them to install. The problem with letting you select multiple bundles is that they can overlap; for example, both bundles might include the basic hotfixes or core applications. Those hotfixes/applications would be installed twice. There is more than one way to handle this. One idea would be to display only atoms, not bundles, in the selection list given by install.pl. (I believe this is roughly what Nils had in mind.) This would be very simple, although it would require that the atoms be pretty "fat", since you would not want too many of them. A more radical idea is to have todo.pl remember which atoms it has already installed to avoid ever installing them again. This would allow an interesting, but fundamental, redesign of todo.pl. Instead of maintaining an ever-changing stack of directives, todo.pl could read a FIXED list of atoms. The todo.txt file would simply designate all of the atoms which "should" be installed on the machine. The todo.pl script would compare that list to the atoms which were already installed, and it would launch the installation script for anything missing. This is interesting because it would allow the use of todo.pl for future maintenance as well as initial installation. All you would have to do is modify the list of atoms in todo.txt and arrange for todo.pl to run. You could even run todo.pl regularly to keep the machine in sync with its desired configuration. (Hm, OpenSMS?) I would envision allowing bundles to be named in todo.txt as well. By updating the contents of the bundle (which lives on the network), you would automatically update the machines when they next ran todo.pl. This is such a different design that "todo.pl" would become a bad name for it... This is starting to look like a package management system. How about "Poor Man's Package Management" (pmpm.pl)? Or should that be "Poor Person's Package Management"? Or maybe "Trivial Package Management"? I have other ideas for ensuring the atoms get installed in the right order, and letting "bundles" be programs (e.g., to pick the right hotfixes for the operating system), but this message is already long enough. What do you folks think? - Pat ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ unattended-info mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unattended-info ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ unattended-info mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unattended-info
