| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 22/07/14 04:51 PM, Andreas K. Huettel wrote: |
| 5 |
> Am Dienstag 22 Juli 2014, 22:40:03 schrieb Ulrich Mueller: |
| 6 |
>>>>>>> On Tue, 22 Jul 2014, Martin Vaeth wrote: |
| 7 |
>>> PF has to be filled correctly, of course: The versions foo-1 |
| 8 |
>>> and foo-1-r0 are identical according to PMS and should thus |
| 9 |
>>> lead to the same $PF. |
| 10 |
>> |
| 11 |
>> This is not so. These versions are equal in comparision, so they |
| 12 |
>> cannot be in the tree at the same time. However, PF will be |
| 13 |
>> different for them. |
| 14 |
> |
| 15 |
> Well we'd need a new EAPI for this anyway. So we might as well |
| 16 |
> redefine -r0 there. |
| 17 |
> |
| 18 |
|
| 19 |
I still don't follow why we need new EAPI for this, as presented. |
| 20 |
What we are talking about here is optional PM behaviour only, and a |
| 21 |
convention that developers will need to adopt. It doesn't much matter |
| 22 |
if a PM doesn't implement minor-revision-vdbonly-merging because that |
| 23 |
PM would just do a full re-emerge same as any other revbump. |
| 24 |
|
| 25 |
The only need for EAPI change that I can see is to allow non-integer |
| 26 |
revision values, but that wasn't on mva's list of changes from what I |
| 27 |
remember. Am I missing something else, here? |
| 28 |
|
| 29 |
-----BEGIN PGP SIGNATURE----- |
| 30 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 31 |
|
| 32 |
iF4EAREIAAYFAlPPtWIACgkQ2ugaI38ACPCjBQD+K0aQW3lJqVUJTo1nO9nnFlsY |
| 33 |
NfrgaIuu6eescdN6FDkBALwizKGBI4I0iSmj2ywis/4OTNsvFBQm9sxywXq7HFz1 |
| 34 |
=3Ajb |
| 35 |
-----END PGP SIGNATURE----- |
Archives