Gabor Gombas <[EMAIL PROTECTED]> writes: > libkrb5-dev Conflicts: heimdal-dev > ==================================
> The problem here is that this "Conflicts:" assumes that the system has > just one user, which is simply not true. Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts assumes that the two packages, er, conflict. Namely, they provide identically-named include files which define different ways of implementing roughly the same API. I'd love to have heimdal-dev and libkrb5-dev peacefully coexist since I personally use both, but since they both implement the same API, this is rather difficult to do. Please note that using pbuilder works around this issue fairly well for building Debian packages, although I realize that this is far from solving every application. > pkg-config comes handy again. If every package provides a .pc file, then > conflicting libraries and headers can simply be moved to separate > directories (/usr/lib/heimdal, /usr/lib/mit-krb5, /usr/include/heimdal, > /usr/include/mit-krb5) and can peacefully coexist. I don't consider this to be a good solution. #include <krb5.h> is part of the API, and forcing all packages that want to build with Kerberos to use special compiler flags to find include files in non-standard locations seems to me to defeat the entire point of the FHS. (I didn't think separating the libraries was necessary; don't they use non-conflicting names already?) The only solution that seems feasible to me would be using alternatives for all of the conflicting header files, and that solution doesn't exactly fill me with glee. I would also question whether running update-alternatives is really that much easier than simply installing the other -dev package and letting aptitude do its thing. (Note that there are other conflicts between MIT Kerberos and Heimdal that aren't really necessary, though, and I *would* find it reasonable to use alternatives for the command-line utilities like kinit. This is something that's on my long-term to-do list, and if one of the Heimdal maintainers wanted to work with me on that, we could probably make many of those conflicts go away.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
