[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Mon, Feb 19, 2001 at 05:01:11PM +1100, Brian May wrote:
> Chris> (1) Convince Debian to upgrade to the (presumably) superior
> Chris> com_err from Heimdal as the standard. I'm assuming that
> Chris> the Heimdal stuff would be sufficiently capable of
> Chris> supporting all the programs which rely on MIT-like com_err
> Chris> behavior. While this would probably get Debian a better
> Chris> com_err it seems to add a lot of overhead for such a
> Chris> trivial package. Is the KTH com_err available as a
> Chris> separate package from anywhere?
> I think this is a good long term goal...
> Why should e2fsprogs use an out of date version of com_err?
> (can't comment on Redhat here, but I assume that it uses libcom_err
> for e2fsprogs, too).
I think most Linux distributions simply use the one from e2fsprogs because
they /need/ e2fsprogs so it's one of the first things that gets built. I
don't think it's so much that the e2fsprogs com_err is out of date as it is
that the KTH one has some incompatible extensions. Based on Jacques'
message, this may be a reasonable approach. Don't suppose you've spoken to
either Ted T'so (author of e2fsprogs) or Yann Dirson (Debian maintainer)
> Chris> (2) Modify the Heimdal .et files so they don't rely on the
> Chris> KTH extensions. While the PREFIX extension seems nice and
> Chris> sensible, removing it would increase compatibilty.
> What do these extensions do? Are they really required? How much
> benefit are they?
As far as I can tell, the one that causes problems is PREFIX.
error_code ASN1_BAD_TIMEFORMAT, "ASN.1 failed call to system time library"
error_code ASN1_MISSING_FIELD, "ASN.1 structure is missing a required field"
error_code BAD_TIMEFORMAT, "ASN.1 failed call to system time library"
error_code MISSING_FIELD, "ASN.1 structure is missing a required field"
Seems reasonable, it just happens to be incompatible. Since the MIT
compile_et doesn't understand PREFIX, you end up with
> I would like to:
> 1. split libcom_err and libss from all programs that use it.
Agreed. It sucks having programs depend on external libraries,
however I think the current situation sucks more.
> 2. rewrite the API, if required, so it supports all features that all
> programs *should* need. See 1..4 above.
I don't know what this would involve. As far as I've seen, the com_errs out
there are generally ABI compatible. I know that the MIT krb5 ss has at
least one API change which makes it source and binary incompatible with all
others (but is easy to reverse).
I suppose the real question is whether it would be possible to convince all
consumers to trade in their local copies of com_err and ss for a centrally
..ooOO email@example.com | 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..
- From: Chris Chiappa <firstname.lastname@example.org>
- Re: com_err
- From: Brian May <email@example.com>