Kestutis:
As I've mentioned on VRVS, I was trying to install software to $VO_BALTICGRID_SW_DIR via pacman (http://physics.bu.edu/pacman/). Here are the results:
+ simple, usable, has good feature set.
+ can be used to build from source. Python build package is included, I'm trying to do something similar for OpenMPI. No serious problems yet.
+ good error handling
- "shell" output discarded. Redirecting to file is possible, so it is not a serious problem.
- missing commands. For example "mkdir()" exists, but "rmdir()" is missing. Workaround is "shell('rm -r')". I expect there will be more missing comands, which exist in usual shell language. In most cases it should not be a problem.
- gsiftp://.... urls were working on UI, but not working on WN. Pacman uses "globus-job-run" to get listing of folder contents. So I switched to http://.... and it works well. This issue needs more debugging, but it is not urgent as long as http is usable.
- a bit restrictive license (You can't distribute modified pacman without author's permission until 2009). This may become a problem if we try to fix gsiftp:// or add BG repository to the predefined list. I would prefer software without such restrictons.
- trusted.caches handling. This file lists package sources, which are accepted. First time You use new "untrusted" cache You get interactive prompt to accept or reject it. Text in this file says You can modify it by hand, but when I did it, one installation went ok, but after that my cache was deleted from the list. Workaround is "pacman -allow trust-all-caches".
Overall my impression it is usable system. If we'll chose pacman, we need to decide where to put pacman itself and its data. Currently I'm doing all tests on ce.bg.ktu.lt:$VO_BALTICGRID_SW_DIR/ktu/ (You can see the results via gsiftp). No software is currently installed there yet.
I don't see any built-in security mechanisms in pacman. If gsiftp would work, I think it would be enough, but downloading packages via http without any integrity testing may become a security hole.