1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 07/07/12 07:29 AM, Peter Stuge wrote: |
5 |
> Zac Medico wrote: |
6 |
>>>>>>> I'd suggest a special ebuild phase to check for ABI |
7 |
>>>>>>> changes, like the pre_pkg_preinst_abi_check phase |
8 |
>>>>>>> suggested here: |
9 |
>>>>>>> |
10 |
>>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 |
11 |
>>>>>> |
12 |
>>>>>> I guess, that phase would detect ABI change and package |
13 |
>>>>>> manager would know how to handle it by itself? |
14 |
>>> |
15 |
>>> Yeah, it would be like a warning system, |
16 |
>>> |
17 |
>>> And once we bump SLOT/ABI_SLOT, package manager would know |
18 |
>>> about how to handle that situation and rebuild needed stuff? |
19 |
> |
20 |
> Is it unrealistic to assume that upstream ABI providers will mark |
21 |
> their ABIs by using sonames correctly? |
22 |
> |
23 |
> Maybe that is at least the common case, then ABI_SLOT could be set |
24 |
> automatically. |
25 |
> |
26 |
> Maybe I'm too far ahead, and baby steps are better. |
27 |
> |
28 |
|
29 |
Although we have a lot of this information available (which is why/how |
30 |
@preserved-libs works, for instance), there is no way for portage to |
31 |
know *prior to emerging the update* if abi has changed. This is why |
32 |
it needs to be specified in the ebuild somehow (and sub-slots via |
33 |
4-slot-abi seem very capable of handling this) |
34 |
|
35 |
That said, while experimenting with 4-slot-abi porting on my overlay, |
36 |
usually I am just specifying the major (or sometimes major.minor) |
37 |
version parts of the sonames, since that seems to make the most sense |
38 |
usually. |
39 |
|
40 |
|
41 |
|
42 |
-----BEGIN PGP SIGNATURE----- |
43 |
Version: GnuPG v2.0.19 (GNU/Linux) |
44 |
|
45 |
iF4EAREIAAYFAk/4Q2IACgkQ2ugaI38ACPBzagD/blTq3Dq1K9Yrv2PdxSirxwu7 |
46 |
POUSNlLr59x8jKaE2oYBAIS+mATPRj3vn1W/uB37ipLmbg76gbcr7LTqh6Mb7Unv |
47 |
=VKuj |
48 |
-----END PGP SIGNATURE----- |