[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
com_err
As anyone who's played with Kerberos and friends knows, I'm sure, there are
way too many software packages out there that bundle com_err and/or ss with
them. Generally this is more an annoyance than anything else; you can
usually trick programs into using another's so you don't end up with too
much clutter on your hard drive. I'm having a bit of challenge achieving
this with Heimdal however. Specifically, I'm trying to build some local
packages for a Debian system. Debian (and others, Redhat for one) includes
a "canonical" libcom_err derived from the e2fsutils. Unfortunately,
(1) Heimdal cannot use the Debian compile_et because it uses a "PREFIX"
extension in .et files which isn't supported by the MIT-derived compile_et.
(2) Other programs which wish to use Heimdal's generated _err.h files won't
be able to because they require com_right.h, requiring Heimdal's com_err to
be installed.
This leaves one in the bad position of being forced into installing two
incompatible versions of com_err on their system.
I'm looking for suggestions on how one would resolve this. The options that
spring to mind are
(1) Convince Debian to upgrade to the (presumably) superior com_err from
Heimdal as the standard. I'm assuming that the Heimdal stuff would be
sufficiently capable of supporting all the programs which rely on MIT-like
com_err behavior. While this would probably get Debian a better com_err it
seems to add a lot of overhead for such a trivial package. Is the KTH
com_err available as a separate package from anywhere?
(2) Modify the Heimdal .et files so they don't rely on the KTH extensions.
While the PREFIX extension seems nice and sensible, removing it would
increase compatibilty.
(3) As an alternative to (2) perhaps an autoconf switch for Heimdal which
could (At the user's request) use the installed com_err and preprocess the
.et files to get rid of PREFIX.
(4) Modify the KTH compile_et so that it generated MIT-compatible _err.h
files (ie that only #include <com_err.h>). Seems ugly as it looks offhand
like the data structures they want are different.
I'm somewhat keen on (2) or (3) myself; (2) could be kept as a local
modification without too much pain. It might be nice to spare others these
problems however. Comments? Criticisms? Suggestions? Flames? I'm all
ears.
--
..ooOO chris@chiappa.net | My opinions are my own OOoo..
..ooOO Chris.Chiappa@oracle.com | and certainly not those OOoo..
..ooOO http://www.chiappa.net/~chris/ | of my employer OOoo..