Re: com_err

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Chris" == Chris Chiappa <griffon+heimdal-discuss@snurgle.org> writes:

(FYI: See my message I previously posted on this subject:
<URL:http://www.stacken.kth.se/lists/heimdal-discuss/2000-10/msg00057.html>)

    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).

    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?

    Chris> (3) As an alternative to (2) perhaps an autoconf switch for
    Chris> Heimdal which could (At the user's request) use the
    Chris> installed com_err and preprocess the .et files to get rid
    Chris> of PREFIX.

I don't like this myself. The autoconf script for Heimdal is already
one of the most complicated autoconf scripts I have ever seen...

    Chris> (4) Modify the KTH compile_et so that it generated
    Chris> MIT-compatible _err.h files (ie that only #include
    Chris> <com_err.h>).  Seems ugly as it looks offhand like the data
    Chris> structures they want are different.

    Chris> I'm somewhat keen on (2) or (3) myself; (2) could be kept
    Chris> as a local modification without too much pain.  It might be
    Chris> nice to spare others these problems however.  Comments?
    Chris> Criticisms?  Suggestions?  Flames?  I'm all ears.

I would like to:
1. split libcom_err and libss from all programs that use it.
2. rewrite the API, if required, so it supports all features that all
programs *should* need. See 1..4 above.
3. fix programs so that they support the resulting library.

The library should have a higher major version number so that the old
library continues to work fine until programs are updated.
-- 
Brian May <bam@snoopy.apana.org.au>