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

Re: Major changes to Heimdal in Heimdal 0.3e-5



>>>>> "Daniel" == Daniel Jacobowitz <dan@debian.org> writes:

    Daniel> Why is depending on kerberos4kth such a horrible
    Daniel> situation?  Remember, Policy advises that when a package
    Daniel> can be built with an optional feature, even if it implies
    Daniel> an additional dependency, we should do so. I'm sure I'm
    Daniel> not the only one who needs to use krb4 and would like to
    Daniel> have krb5...

Its not just that, but the number of changes I have incorporated into
Heimdal which are not getting incorporated upstream. I send patches
upstream, but unless they are really simple ones, I never even get an
acknowledgement. I don't like deferring from upstream too much, but I
have 800 lines of patches just to fix various problems I have found in
shared libraries.

The problem, I think, is being that adding a patch to fix library
dependency problems is not nearly so worthwhile as incorporating new
features, fixing potential security bugs, etc. (No disrespect meant
for the upstream authors). Not to mention this "real-life" job,
whatever that means ;-)

Adding krb4 support for instance, tries to pass the parameter:
-R /usr/athenas/lib

while really confuses gcc. I think it is meant to be --rpath, but even
that needs to be removed to comply with Debian policy.

Those issues aside (I have already fixed that specific problem), I am
still getting more problems, eg:

gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../lib/roken -I../../lib/roken -I/usr/include -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -c afssys.c  -fPIC -DPIC -o afssys.o
In file included from afssys.c:34:
kafs_locl.h:111: parse error before `CREDENTIALS'
kafs_locl.h:125: parse error before `CREDENTIALS'
make[3]: *** [afssys.lo] Error 1

The line in question looks like:

typedef int (*get_cred_func_t)(struct kafs_data*, const char*, const char*,
                                    const char*, CREDENTIALS*);

I don't have a clue how to fix this problem.
-- 
Brian May <bam@debian.org>



Reply to: