Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
I'll remove it in purge.; there's another bug open effectively for that. However, I think it is generally a good thing if the file exists. Because of the dpkg bug we no longer install it, but I think our users are better served by leaving the file on upgrades.
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
Package: libgssapi-krb5-2 Followup-For: Bug #861218 Hi, It seems that this bug is not completely fixed. The file is not shipped in the package anymore, but as the file was installed in /etc it should explicitly be removed during the upgrade in the maintainer script. Could you please have a look at that? Regards, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
control: severity -1 normal Will remove this file early in buster.
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
It seems like an /etc/gss/mech.d/README-- (or similar) would alleviate the technical problems with having a single file named README, and would be glob-able for consuming software that is adapted to know about a broader convention. It would, of course, be slightly confusing to users even if there is only one file with such a naming scheme, let alone two with identical contents. Would such a scheme be preferable to removing the README entirely for buster? -Ben
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
Hi Sam, On Sun, Apr 30, 2017 at 12:03:30PM -0400, Sam Hartman wrote: > 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. Thank you for taking the time to write down all of this background information. > 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. I'm mainly interested in a long-term fix here. My work on improving cross buildability (and thus multiarchy stuff) in Debian is reaching a point where it can be advertised as a technology preview. It still is rough around a lot of corners. Dropping the file early in the buster cycle sounds reasonable to me. My work is still mainly focused on sid rather than stable releases. Hundreds of bugs with patches are waiting to be applied. > 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 explanation makes a lot of sense to me, but it is not very obvious when looking at the package without much kerberos background and seeing the unversioned directory. Given all of the above, I think we should not fix this bug in stretch. The sequence yielding an installation error is not easy to encounter and requires at least two architectures enabled. It also is easy to work around and I hope that we are seeing a fix in dpkg for it. Thus I think that downgrading the bug below rc severity is reasonable. I still think there is a bug, but it is hard to figure where it actually is. The concept of having shared files in Multi-Arch: same packages was introduced to ease adoption, but it turned out that these shared files cause a lot of headache. Too often, they do differ despite setting M-A:same and as we have seen here, carrying conffiles in M-A:same packages is less than well-tested. Some people (dpkg maintainer Guillem Jover included) argue that allowing shared files was a mistake. I thus try to minimize their presence. Helmut
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
> "Helmut" == Helmut Grohne 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
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
Hi Helmut, On Wed, Apr 26, 2017 at 06:52:58AM +0200, Helmut Grohne wrote: > Package: libgssapi-krb5-2 > Version: 1.15-1 > Severity: serious > Justification: violates policy section 8.2 > > libgssapi-krb5-2 is a shared library package and contains > /etc/gss/mech.d/README. The latter filename does not depend on the > soname of the library and thus does not change when the soname changes. > Thus the package will not be coinstallable a newer soname of the same > library and make system upgrades unnecessarily difficult. This violates > the first sentence from policy section 8.2, which is a must: > > | If your package contains files whose names do not change with each > | change in the library shared object version, you must not put them in > | the shared library package. > > This actually causes problems today, due to a related bug in dpkg, which > does not properly support conffiles in m-a:same packages (#861217). Thanks for the report, and sorry that it is causing problems. I think we will need to discuss the best option given that stretch is frozen and there is at least one other bug that would be nice to fix for stretch outstanding (#860767, currently fixed in experimental). -Ben
Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)
Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious Justification: violates policy section 8.2 libgssapi-krb5-2 is a shared library package and contains /etc/gss/mech.d/README. The latter filename does not depend on the soname of the library and thus does not change when the soname changes. Thus the package will not be coinstallable a newer soname of the same library and make system upgrades unnecessarily difficult. This violates the first sentence from policy section 8.2, which is a must: | If your package contains files whose names do not change with each | change in the library shared object version, you must not put them in | the shared library package. This actually causes problems today, due to a related bug in dpkg, which does not properly support conffiles in m-a:same packages (#861217). Please split the README to a different package (or remove it). Often times a -common package is used for such files, e.g. libldap-common. Helmut
