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----- |