| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 16/06/12 12:18 PM, Ciaran McCreesh wrote: |
| 5 |
> On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge <peter@×××××.se> |
| 6 |
> wrote: |
| 7 |
>> Ciaran McCreesh wrote: |
| 8 |
>>>> Could it work to make automatic signatures of imported ABI, |
| 9 |
>>>> and simply compare signatures when a provider package is |
| 10 |
>>>> updated? |
| 11 |
>>> |
| 12 |
>>> No. |
| 13 |
>> |
| 14 |
>> Can you say why? |
| 15 |
> |
| 16 |
> There's no way for a program to work out what "the ABI" of |
| 17 |
> something is (whatever that means), and there's even less of a way |
| 18 |
> for it to know up-front. |
| 19 |
> |
| 20 |
|
| 21 |
I believe what Peter might've been referring to would be some form of |
| 22 |
hashing of each and every library that is installed by a package. |
| 23 |
Just as a basic idea, one could probably (for instance) grab the |
| 24 |
LTVERSION of a libtool-built library, store that along with the emerge |
| 25 |
info, and link this same version when consumer ebuilds are built |
| 26 |
against it; then if the signatures changes the consumer ebuilds that |
| 27 |
were built against the (now incompatible) old signatures could be |
| 28 |
triggered for a rebuild. |
| 29 |
|
| 30 |
I'm not saying that this is a viable approach, simply describing a |
| 31 |
theoretical way it could be implemented. |
| 32 |
|
| 33 |
One of the "advantages" of going this way, though, is that it would |
| 34 |
probably be EAPI-independent as everything would be done internally by |
| 35 |
the PMS. The primary disadvantages I see is that 1-getting "library" |
| 36 |
signatures would be difficult, 2-many orders of magnitude of |
| 37 |
additional preprocessing would be necessary to build the deptree, |
| 38 |
3-there wouldn't be any viable way for developer-based intervention |
| 39 |
when necessary. |
| 40 |
|
| 41 |
Finally, the above is just an example; I don't want to discuss merits |
| 42 |
of an approach like this or entertain possible implementations. |
| 43 |
|
| 44 |
|
| 45 |
>>> Also, can we stop using the term "ABI" in reference to this |
| 46 |
>>> please? It's misleading. Let's call them sub-slots instead. |
| 47 |
>> |
| 48 |
>> I think ABI fits well though? The situation is that A DEPENDs on |
| 49 |
>> B, and at some point B changes in a way that A must be rebuilt in |
| 50 |
>> order to run - right? |
| 51 |
>> |
| 52 |
>> The only reason that A wouldn't run anymore is that B's ABI |
| 53 |
>> changed? |
| 54 |
> |
| 55 |
> ABI has a fairly specific, technical meaning, which can be |
| 56 |
> misleading in the general case. Is Python bytecode an ABI? |
| 57 |
> |
| 58 |
|
| 59 |
Isn't Python bytecode an ABI, given that it's built or tied to a |
| 60 |
particular version (major.minor) of python?? (i'm actually asking |
| 61 |
here, i avoid python so I don't really know if a .pyc from say |
| 62 |
python-2.5 will just work with python-2.7 or if the original script |
| 63 |
would need to be recompiled) |
| 64 |
|
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 67 |
|
| 68 |
iF4EAREIAAYFAk/fOPMACgkQ2ugaI38ACPCnpQD9Eu8uT2NABFQpb1ym5GeWUs0L |
| 69 |
SY+t0wWh6saGXyfVja8BAIYMB0Q21qukus/rH3gDdf98AZYgOiXA20tg+dQyHZ26 |
| 70 |
=grcA |
| 71 |
-----END PGP SIGNATURE----- |
Archives