Jeremy Baron <jeremy(a)tuxmachine.com> 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.
[...]
I wouldn't want to put the burden on the roots because that
would mean that they have to mangle all the small notes that
project X needs package Y into the puppet manifest which in
most cases - as you noted - will not have much effect. If
instead it'd be up to the project's developers, the workload
lies with who has a) the information needed and b) the moti-
vation.
On second thought though, I think ~/.something is too
hidden. We already have the nice [[Template:Tool]] on the
Toolserver Wiki; it would be much better to store the depen-
dencies as fields thus encouraging developers to update (or
create) their pages there and give them more "publicity".
Tim