| 1 |
Ian Stakenvicius wrote: |
| 2 |
> > Is it unrealistic to assume that upstream ABI providers will mark |
| 3 |
> > their ABIs by using sonames correctly? |
| 4 |
> > |
| 5 |
> > Maybe that is at least the common case, then ABI_SLOT could be set |
| 6 |
> > automatically. |
| 7 |
> |
| 8 |
> Although we have a lot of this information available (which is why/how |
| 9 |
> @preserved-libs works, for instance), there is no way for portage to |
| 10 |
> know *prior to emerging the update* if abi has changed. |
| 11 |
|
| 12 |
Knowing that a library changes ABI before building is nice, but not |
| 13 |
relying on a human to encode this is nicer still. |
| 14 |
|
| 15 |
After compile, before install, there is an opportunity to show the |
| 16 |
effects of installing the package. |
| 17 |
|
| 18 |
I'm only talking about the context of the developer who is adding the |
| 19 |
new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just |
| 20 |
once, in the process of committing the ebuild. No need to repeat the |
| 21 |
binary analysis - except if one source package has different ABI for |
| 22 |
different ARCHes. Fun! |
| 23 |
|
| 24 |
|
| 25 |
//Peter |
Archives