[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Condor-devel] Official Debian package for Condor
- Date: Tue, 7 Dec 2010 15:42:54 -0500
- From: Michael Hanke <michael.hanke@xxxxxxxxx>
- Subject: [Condor-devel] Official Debian package for Condor
Hi,
I'm a Debian developer who is currently looking into an official
packaging of Condor for the Debian archive. What I want to achieve is,
one one hand, a fully functional package that incorporates the best
features of all previous packaging attempt (the condor CPack approach,
the debconf setup of the 6.X packaging and the current Ubuntu
packaging). On the other hand the packaging needs to be fully compliant
with the Debian policy. On a rather personal side, we also want to
switch our local cluster from SGE to condor -- which will serve as a
testbed for this effort. After having worked on the current stable code
for a bit I was pointed to the git repository by condor-admin and felt
pure joy seeing the new CMake setup and full history since the beginning
of time.
I'm compiling a list of questions regarding the packaging -- most of
them concerning a proper port to Debian's glibc. In the meantime I'd be
glad if I could have some feedback on the following to topic:
1. You distribute the classad library as a separate package, arguing
that it could be useful outside the scope of condor. For this reason
I also want to package it separately. Do you guarantee that the
latest available classads download is compatible with the most recent
condor? Or in other words, where is the canonical source for
classads: is it the condor Git repository, or is it the dedicated
classads tarball?
2. Is there any reason why all libraries in condor are enforced to be
statically linked? I'd rather compile shared libs for internal
convenience libs instead of artificially inflating binaries and
package size by duplicating symbols. I understand that some libs have
to be static for good reasons, but clearly this doesn't have to be the
case for all those that do not get installed anyway in the current setup.
Could condor use a CONDOR_LIB macro instead of CONDOR_STATIC_LIB for
all libraries that could also be dynamic? By default CONDOR_LIB could
also build static ones (to keep the default setup unchanged), but it
would offer a way to tell cmake to switch to dynamic ones if desired,
without having to patch the code.
Thanks,
Michael
--
Michael Hanke
http://mih.voxindeserto.de