[AG-TECH] Problems while installing AGkt2.2 from source on a Debian
dgolden at cp.dias.ie
Thu Jun 10 08:54:01 CDT 2004
On Thu, 2004-06-10 at 03:07, Joseph wrote:
> Me once again... I hope I annoy noone, otherwise let me know and I will
> remove you from the cc list and/or try to send less mails.
Please CC me, anyway. I dunno, perhaps the setup of an AG-PKG mailing
list would be appropriate, but maybe not (large overlap with ag-tech)
> BTW, in the spec file, they also run /etc/profile/gpt.sh, which I don't
> have on my pc, so I don't know what it's supposed to do. I assume it's
> something linked with the global variables, but I'm not sure.
The gpt.sh file sets GPT_LOCATION (these's something similar for
GLOBUS_LOCATION), a mandatory environment variable - unfortunately,
mandatory env vars are usually not allowed in official debian packages,
packages are supposed to have "sensible defaults" e.g.
/usr/lib/globus or /usr/lib/gpt. Packaging globus is by far the most
problematic part if you ask me, and I have heard nothing further about
the debian intent-to-package it, so I think we can assume
it's up to us.
> BTW, I would gladly take any feedback from other people trying the same
> thing as me.
The binary releases convert across readily with "alien", but that is
not the point of the exercise...
I am still just trying to work my way through the debian policy manual
and new maintainers guide (see debian site - I assume you've seen them
if you're looking at debian packaging), so I am no authority on these
things. A thing to note is the addendum for debian python packaging
policy: If you have debian python installed, see
The following is all IMHO:
Looking at the 2.2 bundle with a view to producing a debian
source package or packages:
No need to include these, they're in python 2.3
>>>>> Separate packaging
gt3.0.2-source-installer Now at version 3.2 "pre-WS".
I that it might be appropriate to separate out globus packaging. But
>>>>> Packaged for debian
I think this is unmodified in the AG bundle, so safe to use debian
>>>>> AG-Specific sources:
These packages are original to accessgrid or modified for accessgrid
I currently think a single-source-tarball, multi-binary-packages method
is most appropriate - i.e. the "debian" directory (very roughly
analogous to the rpm spec file - alien is a very good name for rpm/deb
conversion...) in the root dir of the bundle, building all
of the following (presumably by debian/rules immediately calling the
BuildSnapshot.py script - I'm not talking about supplanting the existing
build system, just complying with debian packaging methods so that
autobuild stuff works):
Modified vic+rat for accessgrid.
vaguely worth noting that openmash + other rat+ vic versions in debian.
Modified for Accessgrid.
Debian version exists. "python-soappy" currently v 0.11.3
If soappy really is going to need to be modifed on an ongoing basis
(Thomas D. Uram said there was "one small change from 0.11.4", then it
would be nice if, like pyOpenSSL_AG, it could coexist with debian
python-soappy, otherwise a package conflict will have to be registered.)
Included here as a dependency of soappy???
Now at version 0.70 N.B. fpconst is silently included in Debian's
python-soappy (personally, I think that is a mistake and debian should
have a python-fpconst package that python-soappy depends on...)
Modified for Accessgrid
Debian version exists. "python-pyopenssl" currently v 0.5.1-4
AG uses unreleased CVS.
Releases are on
If it was a thing that AG could work against a released version, I
think it would be better to use a release.
>>>>> Additional Dependencies (debian package names)---------
Stuff that needs to included as runtime dependencies:
not exhaustive list atm:
--Additional Build Dependencies (debian package names) ----
Stuff that needs to be include as build-time dependencies
Not exhaustive list atm:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the ag-tech