| 1 |
On 02/24/2013 10:40 PM, Duncan wrote: |
| 2 |
> Michael Mol posted on Sun, 24 Feb 2013 22:17:56 -0500 as excerpted: |
| 3 |
> |
| 4 |
>>> I'm not following you here. 'slot' means a very specific thing. You are |
| 5 |
>>> not actually suggesting we use SLOT, you simply want both versions of |
| 6 |
>>> the library to be installed in one ROOT? |
| 7 |
>>> |
| 8 |
>>> I would not advocate this approach. You should strive to have only one |
| 9 |
>>> kerberos implementation on a given machine. |
| 10 |
>> |
| 11 |
>> I'm really not certain, to be honest. It was my impression that slots |
| 12 |
>> allow for two different versions of a thing to be present on the same |
| 13 |
>> system, and that their different sonames on the system would lead to |
| 14 |
>> correct symbol resolution. (Although it would require that the soname |
| 15 |
>> being sought be adjusted in a dependent program to target the version |
| 16 |
>> required.) |
| 17 |
> |
| 18 |
> The issue is in one's definition of "two different versions of a thing". |
| 19 |
> |
| 20 |
> "Slot", in the gentoo sense, has the meaning of two different versions of |
| 21 |
> the same package, say qt-3 (tho that's long out-of-tree, but alive in kde- |
| 22 |
> sunset) and qt-4 and qt-5 (tho that's very new, but is or will soon be a |
| 23 |
> problem as more packages dep on it), where there'd ordinarily be file and/ |
| 24 |
> or functionality collisions, NOT two different packages containing the |
| 25 |
> same functionality, which is the extended meaning it appears you're |
| 26 |
> applying here, but which only confuses people when used within the gentoo |
| 27 |
> context. |
| 28 |
> |
| 29 |
|
| 30 |
My presumption was that both app-crypt/heimdal and app-crypt/mit-krb5 |
| 31 |
used the same binary names. |
| 32 |
|
| 33 |
$ equery f app-crypt/mit-krb5|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e |
| 34 |
's/.*\///'|sort -u|grep -v debug |
| 35 |
db2 |
| 36 |
encrypted_challenge |
| 37 |
libgssapi_krb5 |
| 38 |
libgssrpc |
| 39 |
libk5crypto |
| 40 |
libkadm5clnt |
| 41 |
libkadm5clnt_mit |
| 42 |
libkadm5srv |
| 43 |
libkadm5srv_mit |
| 44 |
libkdb5 |
| 45 |
libkrb5 |
| 46 |
libkrb5support |
| 47 |
pkinit |
| 48 |
|
| 49 |
(on a different machine) |
| 50 |
|
| 51 |
$ equery f app-crypt/heimdal|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e |
| 52 |
's/.*\///'|sort -u|grep -v debug |
| 53 |
libasn1 |
| 54 |
libgssapi |
| 55 |
libhcrypto |
| 56 |
libhdb |
| 57 |
libheimbase |
| 58 |
libheimntlm |
| 59 |
libhx509 |
| 60 |
libkadm5clnt |
| 61 |
libkadm5srv |
| 62 |
libkafs |
| 63 |
libkdc |
| 64 |
libkrb5 |
| 65 |
libroken |
| 66 |
libsl |
| 67 |
libwind |
| 68 |
windc |
| 69 |
|
| 70 |
|
| 71 |
The overlap between the two includes libkrb5, libkadm5clnt and |
| 72 |
libkadm5srv. When I was thinking "why not slots?", that was explicitly |
| 73 |
the part I was thinking of. |
| 74 |
|
| 75 |
The distinction between two versions of a thing, and two implementations |
| 76 |
of a thing, is a thorny epistemological issue; "extended meaning" is |
| 77 |
good way to put it. I've acknowledge that abusing slots in this way is |
| 78 |
pretty vile. I don't really care to advocate it; I merely brought it up |
| 79 |
as an alternative. (But it seems it's a difficult question to bridge.) |
Archives