>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious
Helmut> libgssapi-krb5-2 is a shared library package and contains
Helmut> /etc/gss/mech.d/README. The latter filename does not depend
Helmut> on the soname of the library and thus does not change when
Helmut> the soname changes.
Hi.
I'm going to start by explaining why that file is there and asking for
your help in figuring out what to do.
I'm then going to argue that this is not an RC bug (probably not even a
bug at all).
But I'm more interested in finding a solution that works for us both
than simply closing bugs because I can.
The issue is that older versions of krb5 had two related problems with
regard to /etc/gss/mech.d:
1) They only supported a config file for reading mechanism config, not
an entire directory
2) Because of a bug in how I set prefix, they read /usr/etc/gss/mech not
/etc/gss/mech as that config file.
Nothing shipped /usr/etc/gss/mech on Debian--it's clearly not
FHS-compatible.
However, there are some gss mechanism packages, mostly not in Debian,
that need to configure themselves even on older krb5.
I needed a way to figure out whether the gss library was new enough to
read /etc/gss/mech.d.
So I dropped a README in that directory. Code that detects that file
and uses it as a flag not to create and write /usr/etc/gss/mech has
escaped. The main culprit is moonshot-gss-eap (especially versions not
in Debian), but I've recommended the approach to others and not tracked
where all it might be being used.
I think we can move away from that approach for stretch +1, but I really
kind of need that file to be there, and I'm quite uncomfortable trying
to get the replaces/conflicts/provides dance correct this late in the
stretch cycle.
So, that's why I care about the file for stretch, and why I want to be
careful about a fix.
I claim this is not a violation of policy 8.2. In particular, It seems
very likely that if the soname of libgssapi_krb5 changes, you'll need
different mechanism configuration for the new version. It seems very
unlikely that the same mechanism will work for GSS v2 and v3. So, I'd
expect the directory to be /etc/gss3/mech.d or /etc/gss/mech3.d, and if
the readme were retained, I'd expect it to be in that new directory in
the new library.
That said, I'll note that libgssapi_krb5.so.2 has been stable since
before the release of Kerberos 1.0 back in 1995. A change in gss's
soname is going to be a huge massive pain in all sorts of ways if it
ever happens, and I don't think having to deal with one README is going
to even make the headache list.
You said that you're running into dpkg issues.
I'm sympathetic to that, but I'd like to find a way that your needs and
mine can both be met.
--Sam
