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
