| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Thu, 07 Jun 2012 15:14:03 -0400
|
| 5 |
Ian Stakenvicius <axs@g.o> wrote:
|
| 6 |
> How is the case of something like libpng going to be handled, where we |
| 7 |
> only support one API (and so only one SLOT)? Either in the proposed |
| 8 |
> ABI_SLOT thing or when using slot operators? |
| 9 |
|
| 10 |
Ideally, by you putting in the work and supporting more than one API,
|
| 11 |
since doing so vastly improves the user experience.
|
| 12 |
|
| 13 |
Failing that, SLOT plus blockers. Then if it turns out that really
|
| 14 |
doesn't work (and it's not just developers being utterly lazy), either
|
| 15 |
ABI_SLOT or parts in a future EAPI.
|
| 16 |
|
| 17 |
> For the slot-operator case, will every consumer of libpng be forced to |
| 18 |
> change their dep to libpng:= to ensure they get rebuilt when libpng |
| 19 |
> bumps from 1.5 to 1.6?? |
| 20 |
|
| 21 |
Every consumer of libpng that wants to improve from the current
|
| 22 |
situation, yes.
|
| 23 |
|
| 24 |
- --
|
| 25 |
Ciaran McCreesh
|
| 26 |
-----BEGIN PGP SIGNATURE-----
|
| 27 |
Version: GnuPG v2.0.19 (GNU/Linux)
|
| 28 |
|
| 29 |
iEYEARECAAYFAk/Q/dMACgkQ96zL6DUtXhFlgQCaAr/9xTL8/bwTHbqud5ETo1fN
|
| 30 |
T64An077XiZVmdP+/76KBTdRVlaDa4U2
|
| 31 |
=se/J
|
| 32 |
-----END PGP SIGNATURE----- |
Archives