| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Carsten Lohrke wrote: |
| 5 |
> On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: |
| 6 |
>> ~ * The meaning of the !atom blocker syntax now implies that |
| 7 |
>> ~ temporary simultaneous installation of conflicting packages is |
| 8 |
>> ~ allowed [3]. |
| 9 |
>> |
| 10 |
>> ~ * A new !!atom blocker syntax is now supported, for use in special |
| 11 |
>> ~ cases in which temporary simultaneous installation of conflicting |
| 12 |
>> ~ packages should not be allowed. |
| 13 |
> |
| 14 |
> I didn't really look into the issues, intended to be resolved with this, but |
| 15 |
> I'm somewhat suspecious that this is merely a hack around inaccurate |
| 16 |
> dependency listing in ebuilds on the one side and Portage's dependency |
| 17 |
> resolver issues on the other. |
| 18 |
|
| 19 |
Well, I'm open to alternative suggestions. Please see the previous |
| 20 |
email in which I've attempted to explain the reasoning for the given |
| 21 |
approach [1]. It seems to me that this approach is well suited for |
| 22 |
solving cases in which temporary simultaneous installation of |
| 23 |
blocking packages is needed. |
| 24 |
|
| 25 |
> What I do strongly oppose is changing the meaning of the '!' symbol, as |
| 26 |
> blockers, which should remain real blockers will not be adjusted by us, when |
| 27 |
> changing an ebuild to EAPI 2++ in every case, since we're humans after all. |
| 28 |
> So, if you implement this, keep '!' as is and find another symbol for |
| 29 |
> these "soft" blockers. |
| 30 |
|
| 31 |
Again, please see my previous email on this subject [1]. The reason |
| 32 |
that I think we should change the meaning of the '!' symbol is that |
| 33 |
the majority of existing EAPI 0 or 1 blockers appear to fit the new |
| 34 |
meaning already. So, we'll only have to use the new !!atom syntax |
| 35 |
for special cases in which temporary simultaneous installation of |
| 36 |
blocking packages must be explicitly forbidden. |
| 37 |
|
| 38 |
>> ~ * A new src_prepare phase function is called after src_unpack. |
| 39 |
>> |
| 40 |
>> ~ * The old src_compile phase function is split into separate |
| 41 |
>> ~ src_configure and src_compile fuctions. |
| 42 |
> |
| 43 |
> All I do see is more complexity, but no real benefit. |
| 44 |
|
| 45 |
My impression is that most people tend to see these as useful |
| 46 |
extensions despite the slight increases in complexity. |
| 47 |
|
| 48 |
> |
| 49 |
> Carsten |
| 50 |
|
| 51 |
[1] |
| 52 |
http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml |
| 53 |
- -- |
| 54 |
Thanks, |
| 55 |
Zac |
| 56 |
-----BEGIN PGP SIGNATURE----- |
| 57 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 58 |
|
| 59 |
iEYEARECAAYFAkjNR5sACgkQ/ejvha5XGaPR0gCgkiG7H4HZ4ASh/SyLboFGTCix |
| 60 |
50EAmwU6WWU3gx5GV+EU1NqRmY+s4fDb |
| 61 |
=rbQz |
| 62 |
-----END PGP SIGNATURE----- |
Archives