Ray wrote:
On Tue, 28 Nov 2006, Robert Lupton wrote:
The manifest is written by interrogating the eups "database", so
eups distrib
is basically just a clone operation.
Is this a local database or a remote one? In the from-scratch
case, this would have to come from a remote source of some sort.
(I was a little unclear about how eups_distribute did this.)
There are two steps:
eups distrib --create
which is run on a machine with everything setup (and working!), and
eups distrib --extract
The latter pulls down a manifest, which basically tells it which
products it'll need, and the product tarballs. These tarballs
contain the table files which allow --extract to run eups declare.
At the end of all this, we've cloned a product.
I was imaging that I'd add an option to
use pacman as the "transport layer". I even started looking at
implementing
this, when I discovered that pacman didn't seem to have a way to
say, "Install
this _here_" so I got discouraged and went on to other matters.
...
Pacman creates its "database" in a subdirectory called
"o..pacman..o" in the directory from which you run it. You can run
pacman from any directory; however, if you want it to have any
memory of what it's done before, you need to run it from the same
directory. Thus in the demo, I have users change into the flavor
directory; installations are made into locations relative to that
directory.
...
The possible solution is in the fact that my pacman scripts do not
install into absolute locations, but rather in fixed locations
relative to the directory where pacman is run.
This seems sensible and workable. Let me see if I can implement this
as a transport layer below eups distrib. If it's a mess, we can look
into moving the smarts into pacman.
R
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
