Re: Bug#852395: unblock: gssproxy/0.5.1-2

[Daniel Pocock <daniel@pocock.pro>]

On 05/03/17 19:42, Niels Thykier wrote:
> On Sat, 04 Feb 2017 09:58:00 +0000 Niels Thykier <niels@thykier.net> wrote:
>> Daniel Pocock:
>>> [...]
>>>
>>> Upstream is not really supporting rpc.svcgssd any more, they actually
>>> disabled it in the build so people can still have it as a transitional
>>> measure in stretch.
>>>
>>> People shouldn't be using it in any new installations.  Offering them
>>> gssproxy is a very sensible thing to do.
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>> Debian kernel team <debian-kernel@lists.debian.org>
>> Ok, follow up questions:
>>
>>  * Do you have an upstream reference to the state of rpc.svcgssd?


http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=24b5d60d7f0a514310df810e3eb27b72f665febf

"svcgssd: Disable support for the rpcsec_gss server by default

At this point the gssproxy is better option than the
svcgssd so the support is off by default.

Use --enable-svcgss to re-enable the support"

but it looks like it may not be completely abandoned, there have been
other commits that mention gssd recently.


>>
>>  * Can we provide both rpc.svcgssd and gssproxy in Debian (with the
>>    admin choosing) or is it an "xor"?
>>

I think there are two questions:

a) can they both exist in different packages that conflict with each
other?  I'm guessing that will probably be yes.

b) can they both be installed simultaneously?  Possibly not (can anybody
on the linux-nfs list answer?)


>>  * If this package is unblocked, are there any changes needed in
>>    nfs-common needed to support gssproxy?  (source upload, binNMU or
>>    "just works with no further changes")
>>

I don't have time to investigate that right now, if anybody else has
time to look more closely that would be great.

Regards,

Daniel