1 |
On Wed, Sep 2, 2015 at 2:28 AM, Eray Aslan <eras@g.o> wrote: |
2 |
> On Tue, Sep 01, 2015 at 03:24:05PM +0200, Lars Wendler wrote: |
3 |
>> * We should really get heimdal and mit-krb5 packages in a shape where |
4 |
>> we can install them in parallel [2]. Using the bundled heimdal from |
5 |
>> samba is no valid option [3] |
6 |
> |
7 |
> While bundling a copy of a kerberos implementation is certainly not |
8 |
> ideal, I think this is the only sensible option at the moment. |
9 |
> |
10 |
> Re-evaluate when samba's changes end up in a heimdal release we can |
11 |
> package. Some of the changes landed upstream in July, so there has been |
12 |
> some progress recently. |
13 |
> |
14 |
|
15 |
I agree that it may make sense to allow use of a bundled heimdal until |
16 |
this can be remedied. Perhaps control it via a USE flag (which is how |
17 |
chromium approached issues like this as they slowly unbundled things |
18 |
in the earlier days). If the user can install the packaged heimdal |
19 |
that should be the recommended approach, but if not they can use the |
20 |
bundle. |
21 |
|
22 |
I didn't get the impression that changes to heimdal were the issue |
23 |
here, but rather the fact that it blocks mit-krb5. |
24 |
|
25 |
It seems like competing implementations of the same library that don't |
26 |
actually aim to be completely compatible is becoming more of an issue |
27 |
these days. We're seeing it here, and we of course have all grown to |
28 |
love ffmpeg/libav. Since we're source-based we have a lot more power |
29 |
to control these issues, but we probably don't want to have to patch |
30 |
build systems left and right to do it. Where there are simpler |
31 |
solutions we should take them, and if upstream has already helped out |
32 |
with the hacking by bundling that should be considered a practical |
33 |
compromise where necessary. |
34 |
|
35 |
-- |
36 |
Rich |