On Thu, Nov 03, 2005 at 09:07:12AM -0800, Russ Allbery wrote:
> Like I said, this defeats the entire point of the FHS.
What is the "entire point" of the FHS? If it is to disallow alternative
implementations of the same interface to co-exist then the FHS is
broken. Fortunately, this is not my reading the of FHS.
There are already many examples: libglib-1.2-dev and libglib-2.0-dev
provide overlapping interfaces, yet they can be installed together
quite nicely. libgnutlsXX-dev provides part of the interface as
libssl-dev and they can be installed together. If you claim that this is
against the FHS then you are taking away freedom from the users to
choose their preferred implementation of a given interface.
> I'm not saying that using krb5-config is a bad idea. Over time, it's
> gotten better and better. But most Kerberos-using software does not use
> that script for a variety of reasons and patching all Debian packages for
> all of that software to use it is not necessary or particularly desirable
> in my opinion.
But this does not need to happen in an instant. Quick roadmap (might
have some glitches):
- move the conflicting files (headers, libs) to non-conflicting
locations
- provide backward-compatibility symlinks using alternatives
- tell maintainers that when they for the next time upload a package
that Build-Depends: on <one KRB5 implementation> to add a
Build-Conflicts: with <the other implementation>. This should happen
only at the next upload, so noone needs to hurry.
- start converting applications (it might be just as easy as setting
CPPFLAGS/LDFLAGS in debian/rules, depending on the application)
- when enough applications have converted, make the change mandatory
- at some time in the future (etch+1, etch+2...) remove the
compatibility links
Will step 4 take some (a long) time? Sure. But it is not worse nor
more complicated than many other transitions (and Debian is quite
familiar with big and long-running transitions :-)
> It defeats the purpose of the FHS, which is to have files in a predictable
> and consistent location that doesn't require configuring all software that
> relies on those files with special flags.
Face it: many complex software already require such configuration and
this will only become more common, not less. Also, the purpose of the
FHS should never be to take away freedom from me, an ordinary Debian
user, to select _my_ preferred implementation of an interface
_regardless_ of what other -dev packages happen to depend on. Doing so
would be a violation of the Social Contract, which I beleive is stronger
than the FHS.
The FHS only says that include files should go under /usr/include,
libraries under /usr/lib etc. It does not say that they cannot go into
subdirectories (in fact, it even recommends that for complex packages in
case of /usr/lib). Also, it nowhere mentions that conflicting versions
of some software should not live simultaneously under different
subdirectories of /usr/include, /usr/lib etc.
> Sorry, my mistake. I had thought that luckily all of the Heimdal library
> names were different than all of the MIT library names, which I believe is
> almost true *except* for (of course) libkrb5.
Well, if you'd be using krb5-config then you could just rename one of
them without anyone noticing (the old shared library should remain
until all dependent applications are rebuilt, but that's all).
> Anyway, given the vehemence of your response, I doubt you're willing to be
> convinced.
Yes, I'm quite pissed off when I want to install some -dev package (that
I do not even need the Kerberos support of) just for trying it and it
wants to remove heimdal-dev in favor of libkrb5-dev while a compilation
using heimdal-dev is still running in an other window...
Of course, if you have some other solution that unconditionally keeps
heimdal-dev installed (and which does not require rebuilding all
MIT-dependant -dev packages against Heimdal), I'd be interested.
> Given that, I'll just say that, as the co-maintainer of the
> MIT Kerberos package, I will not do what you suggest, and leave it at that
> (at least in the absence of other arguments that strike me as more
> persuasive). If you want the package to change, you can try to convince
> Sam, but I expect he'll have the same objections.
Well, the other option for me is to bug every Kerberos-using package to
also have a version built against Heimdal, but I'm not quite
enthusiastic as except this stupid Conflicts: between the -dev packages
I see no technical reason to do so.
<IMHO flamebait="yes" eat-it="no" what-if-you-did="reply-off-list">
Although this is not a _technical_ reason, it would still be
useful to have both a MIT and a Heimdal-dependent version of
every KRB5-using application. So if the USA goes insane again
about crypto stuff, we will not be left without a working &
tested KRB5 implementation.
</IMHO>
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]
