Hey Robert,
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.)
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. Note that
this
install should be relative to EUPS_PATH and I'd rather not legislate where
that is, although we could.
Here's what I was thinking. When installing a versioned release of some
package--be it one of ours or a 3rd party package--the typical thing will
be to install them into a standard place. (Having a common organization
for the software stack, if nothing else, will ease our debugging
discussions.) Pacman scripts would be written to install them into these
standard locations.
If you want to install them into a non-standard location, you can...
o get the underlying tarball and .table file
o run ./configure; make install yourself
o run eups_declare yourself
This seems reasonably simple; however, it could be easier as I'll explain
below. Note that the above process is essentially the same as for
installing private versions of code from the svn repository, except that
you check out the code instead of grabbing a tarball.
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.
Going the pure pacman route requires that we solve or define away this
absolute path issue,
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.
Note that the user can set up multiple flavor directories in arbitrary
locations. As long as the EUPS_PATH has all these locations, it should
all work. The user would not have to install the entire stack in every
location; she could put just the 3rd party stuff in one location and LSST
packages in another, or mix and match arbitrarily. So this mechanism
gives you some ability to control the location of installations; the only
restriction is that within a "flavor" directory, the location of a package
is fixed.
and also that we find a way to export the eups
knowledge into the pacman scripts.
Yes, one disadvantage to how I'm currently doing things is that
dependencies now exist in two places: the .table file and the pacman
script (template). If we can get pacman script to read the .table file,
we'd be in business. I don't think this would be too hard.
BTW, to see my pacman scripts, have a look at the contents of
http://monet.ncsa.uiuc.edu/~rplante/lsst/pm. You can probably get the
gist of what's going on when you scan the file. (What a developer would
create can be found in http://monet.ncsa.uiuc.edu/~rplante/lsst/m4.)
So what do you think? Do want to look into the "eups distribute" route a
bit more? Is there anything I can do to assist?
cheers,
Ray
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
