On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote:

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

Having the same API is not a problem as long as I can select (using
appropriate -I and -L options) which one do I want.

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

But that does not work well in a multi-user environment. Requiring every
user to have a separate pbuilder environment so they can use their
preferred Kerberos implementation requires a lot of extra disk space,
I/O bandwidth, memory and CPU power. Also, pbuilder might not be that
useful for people working on software that is not Debianized.

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

This is nonsense. People using other OSes routinely build software at
non-standard locations and they do not have any "API" issues at all.
Furthermore, any Kerberos-using application should already use
krb5-config to determine the neccessary compiler and linker flags,
otherwise the application is already buggy as it will not build
correctly on many non-Linux systems where Kerberos is not installed at a
system location.

Also, I do not see any FHS issues here. Heimdal installing headers under
/usr/include/heimdal-krb5 (and .so links under /usr/lib/heimdal-krb5)
while MIT Kerberos installing headers under /usr/include/mit-krb5 (and
.so links under /usr/lib/mit-krb5) is fully FHS-compliant.

> (I didn't think separating the libraries was necessary; don't they use
> non-conflicting names already?)

Which separation do you think of? Both heimdal-dev and libkrb5-dev
contain the /usr/lib/libkrb5.so symlink, so they do conflict unless that
link is moved to some other place.

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

No. As I said krb5-config is already part of the Kerberos build
interface so you only need alternatives for krb5-config.

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

What do you mean by "letting aptitude do its thing"? aptitude would
_remove_ the other -dev package and that is _exactly_ what I have
problem with.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to