HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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