Ray writes:
I looked at the internals of eups_distribute a bit to understand
how to integrate with pacman. Correct me if I got this wrong, but
I surmised that the manifest file attempts to address how to
express a package's dependencies before it's been declared into the
EUPS--a problem I didn't appreciate previously.
I see two possible solutions for this. One is to continue to use
the manifest file mechanism, but to alter eups_distribute to list
pacman scripts instead of tarballs. The other solution is used in
my demo in which has pacman completely replace the use of
eups_distribute. Pacman scripts have a mechanism for expressing
the package dependencies that will automatically install them as
necessary. My pacman scripts, as their last step in the
installation, calls eups_declare to register the package with EUPS.
Firstly, I wrote eups_distrib (you can [now] also say "eups distrib"
--- or
eups help for that matter) about a month ago so it isn't set in
stone, or
even jell{o,y}.
The manifest is written by interrogating the eups "database", so eups
distrib
is basically just a clone operation. 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.
Going the pure pacman route requires that we solve or define away this
absolute path issue, and also that we find a way to export the eups
knowledge into the pacman scripts.
The one thing that I'd really like to keep from pacman is its ability
to build from source. Sure I could hack that into eups_distrib, but
why reinvent the wheel?
R
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
