| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 02/09/15 12:31 PM, hasufell wrote: |
| 5 |
>> In terms of libraries in general, although the SLOT=0 for full |
| 6 |
>> package version / SLOT=somethingelse for binary-only stuff is a |
| 7 |
>> bit of a convention, you need to check what slotting actually |
| 8 |
>> means for every dependency your package depends on because each |
| 9 |
>> one will differ. For instance, sci-libs/opencascade installs |
| 10 |
>> all versions in their own specific slot, headers and all. The |
| 11 |
>> choice generally comes down to what the maintainer of the |
| 12 |
>> library package decides to do . |
| 13 |
>> |
| 14 |
> |
| 15 |
> This is another case where I feel we need better metadata support |
| 16 |
> (or at least some documentation policy/standard, so developers |
| 17 |
> don't go into pitfalls). With the rise of SUBSLOTs this becomes |
| 18 |
> even more a problem, because they also can mean a few different |
| 19 |
> things. |
| 20 |
> |
| 21 |
|
| 22 |
Also true.. In theory, subslot changes should just mean an ABI |
| 23 |
change that will require a rebuild, but in practice things are a lot |
| 24 |
more complicated. It wouldn't hurt, even in terms of maintainer(s) |
| 25 |
keeping track within the package itself, if there was metadata about |
| 26 |
this filed somewhere. |
| 27 |
|
| 28 |
|
| 29 |
|
| 30 |
|
| 31 |
-----BEGIN PGP SIGNATURE----- |
| 32 |
Version: GnuPG v2 |
| 33 |
|
| 34 |
iF4EAREIAAYFAlXnL7UACgkQAJxUfCtlWe1XwwD/TVIFk6dJSYNtsZROduNxCWIN |
| 35 |
2F6Al4Pca7rpqyBQ0WcA/0svJX65zA29gucf+Zf6pb9BPbQF/KtyR2VPuXQRj7tE |
| 36 |
=Na5Z |
| 37 |
-----END PGP SIGNATURE----- |
Archives