| 1 |
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: |
| 2 |
> ~ * The meaning of the !atom blocker syntax now implies that |
| 3 |
> ~ temporary simultaneous installation of conflicting packages is |
| 4 |
> ~ allowed [3]. |
| 5 |
> |
| 6 |
> ~ * A new !!atom blocker syntax is now supported, for use in special |
| 7 |
> ~ cases in which temporary simultaneous installation of conflicting |
| 8 |
> ~ packages should not be allowed. |
| 9 |
|
| 10 |
I didn't really look into the issues, intended to be resolved with this, but |
| 11 |
I'm somewhat suspecious that this is merely a hack around inaccurate |
| 12 |
dependency listing in ebuilds on the one side and Portage's dependency |
| 13 |
resolver issues on the other. |
| 14 |
|
| 15 |
What I do strongly oppose is changing the meaning of the '!' symbol, as |
| 16 |
blockers, which should remain real blockers will not be adjusted by us, when |
| 17 |
changing an ebuild to EAPI 2++ in every case, since we're humans after all. |
| 18 |
So, if you implement this, keep '!' as is and find another symbol for |
| 19 |
these "soft" blockers. |
| 20 |
|
| 21 |
> ~ * A new src_prepare phase function is called after src_unpack. |
| 22 |
> |
| 23 |
> ~ * The old src_compile phase function is split into separate |
| 24 |
> ~ src_configure and src_compile fuctions. |
| 25 |
|
| 26 |
All I do see is more complexity, but no real benefit. |
| 27 |
|
| 28 |
|
| 29 |
Carsten |
Archives