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