On Sun, Mar 4, 2012 at 22:05, Tim Landscheidt <t...@tim-landscheidt.de> wrote: > Which brings me > to: Does anyone know an established format a) in which pro- > jects could write down their requirements and b) that covers > both Debian and Solaris? So when admins need to (re-)in- > stall a server, they wouldn't have to guess which packages > are (still) required, but could just collect all > $HOME/.requirements for active accounts and when one of > these could not be satisfied, there would also be a person > to contact before tools get broken.
I assume this is one of the reasons to use puppet? Puppet manifests can have comments and the roots could establish a standardized way of writing (inline) why a package is needed. (e.g., a) assumed to be widely used like sed, grep or b) needed by the roots or a process that doesn't belong to a particular user or MMP or c) needed by users/MMP foo, baz, bar or some combination of those.) Of course most people (whether roots or users or anyone else) won't do a very thorough job of enumerating dependencies when installing, updating, hacking software unless they first do an installation of that version on a brand new Debian install with a limited set of installed packages. i.e. most people won't notice that a package is needed or not already picked up some other way until they see something is broken because it's missing. I'm not sure if I like ~/.requirements (and maybe it could be something like ~/.package-depends instead?) in place of puppet but at least it could be used as a failsafe if a root wanted to check after installing a new box or before removing a package. This all got me thinking: can SGE be told that a job needs a certain package, choose a box that has it already installed, and keep relevant stats so that roots know if a package should be installed somewhere else as well? -Jeremy _______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
