Does anyone have any suggestions for how to do this?  I'm not able to 
think of any elegant solutions to this problem.  Symlinks in the scripts 
directory won't work because rsync will just copy them as symlinks.  I 
could put together some scripts that automatically copy libraries into 
slack roles' scripts dirs, but that's kind of gross.  Or I could 
*shudder* use hard links, but that's even grosser and not trivial to do 
with a svn-backed slack repository.  I thought about just putting the 
libs in a slack role, but without dependencies between roles, how do I 
ensure that the libraries get installed first?  I also thought about 
just calling slack from within the role's preinstall, but really you'd 
probably want to call slack recursively using the same path to slack and 
with the same options, especially the -s option.  (Make has similar 
issues with recursion, and it deals with it by having users run 
"$(MAKE)" instead of "make" because the former propagates options to the 
recursive make.  I suppose slack could set a SLACKCMD environment 
variable that could deal with this.)
Another option would be to modify slack to support a shared library 
directory that always gets rsynced over along with roles that are 
fetched.  We could add a lib/ directory alongside the etc/ and roles/ 
directories at the base of the slack repository, and always rsync it.  
The downside to this is that in larger installations with many admins 
using slack, the lib directory could easily get unweildy.  Maybe have a 
requires file in the scripts directory that lists what files are needed 
from lib?  Of course, at that point, we might as well just implement 
slack role dependencies.
Thoughts, anyone?
-- 
Steve Atwell <sat...@disjoint.net>
I've wanted something like that for a while.  Maybe it's time to get
the ball rolling. We can make a "slack-utils" package in the repo.  Do
you have some scripts to seed it with?
--Alan
On the one hand, I think the idea of having pre-packaged utilities to do 
everything I want would be nice.  But taking a pragmatic point of view, 
there will always be some OS or distribution or weird site-specific 
behavior that slack-utils doesn't support.  So when I discover that 
there's some new little thing that I want to do, all I have to do is 
write a patch, get the maintainer to accept it, wait for a new release 
to be cut, build a new package, and get the new package installed on all 
my machines.  That's a pretty heavyweight solution to avoiding 
duplication of eight lines of shell script across three slack roles, 
don't you think?
I still think that allowing the individual slack repository maintainers 
to easily drop in their own libraries (or library executables or 
whatever) with minimal fuss is the way to go.
Maybe we could combine your idea and my idea.  We could have a shared 
script area in the slack repository, and then we can put together a 
slack-stdlib with common general-purpose functions that admins can 
install into their repository.
-- 
Steve Atwell <sat...@disjoint.net>
What would be the best way of getting them to the group? Upload to the  
site? Attachments? They aren't that big.
David
http://groups.google.com/group/slack-users/web/slack-addons.tar.gz
Like I said in the README, there's almost no docs anywhere. Right now  
I won't be able to do a lot of work on things like docs and cleanup,  
but I should be able to answer any questions you might have about how  
I did things.
David