| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 16/06/12 12:24 PM, Ciaran McCreesh wrote: |
| 5 |
> On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos <pacho@g.o> |
| 6 |
> wrote: |
| 7 |
>> I can try to check it if no maintainer shows more packages |
| 8 |
>> showing this stable API unstable ABIs issues |
| 9 |
> |
| 10 |
> Please do. This is a fairly important point: if the number of |
| 11 |
> affected packages is small, there's no point in introducing |
| 12 |
> sub-slots. |
| 13 |
> |
| 14 |
|
| 15 |
I don't know about that -- I think we still very much need sub-slots. |
| 16 |
There is still a rather important distinction here -- SLOTS are |
| 17 |
currently used not to specify API, but to specify particular API |
| 18 |
groups that developers of said package are willing to support being |
| 19 |
installed (usually in parallel). For cases when developers decide it |
| 20 |
is not a good idea to support multiple APIs at a time (i go back to |
| 21 |
libpng here as an example of this current practice), 'SLOT=0' is still |
| 22 |
a valuable specification. Sub-slots will allow the actual API to be |
| 23 |
specified in this case (which as has been described will trigger |
| 24 |
rebuilds of consumers when necessary, if consumers *DEPEND on 'pkg:0=' |
| 25 |
or whatever the exact syntax will be) |
| 26 |
|
| 27 |
It's one thing for slot-operators in EAPI=5 to provide new tools to |
| 28 |
ensure better dependency handling; it's something else to assume the |
| 29 |
entire tree is going to be converted so that every package acting as a |
| 30 |
dependency will have a SLOT= reflecting the true API version rather |
| 31 |
than SLOT=0 |
| 32 |
|
| 33 |
-----BEGIN PGP SIGNATURE----- |
| 34 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 35 |
|
| 36 |
iF4EAREIAAYFAk/fO/gACgkQ2ugaI38ACPBlNwD6Aw39lxsdGFSmHUqnzU+37A1P |
| 37 |
Z4x5TAtIrFsk7qK4y80A/RFpvD3J4YL8xonLKDWsey14BsKgq1Yz3VD5wlyDKJFd |
| 38 |
=FhFC |
| 39 |
-----END PGP SIGNATURE----- |
Archives