| 1 |
> The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or |
| 2 |
> gentoo-haskell. |
| 3 |
|
| 4 |
As a part of gentoo-haskell team, I'd like to say that CVS issue is |
| 5 |
not strongest one, there are |
| 6 |
much more meaningful reasons for having much stuff in overlays at |
| 7 |
least for haskell. |
| 8 |
|
| 9 |
IMHO: |
| 10 |
|
| 11 |
The main point that haskell ecosystem is very breaky and only latest |
| 12 |
version is supported, so |
| 13 |
the safest path is to be on a bleeding edge and patch inconsistent |
| 14 |
applications. So if one |
| 15 |
package gets updated then commonly we need to fix its reversed deps, |
| 16 |
if it were in tree than |
| 17 |
we would be involved into stabilization process and in the end will |
| 18 |
delay updating deps, and |
| 19 |
the difficulty of tracking all version variant will be much higher |
| 20 |
than no, at the end the quality |
| 21 |
of the packages in tree will fall. Really we can _guarantee_ that |
| 22 |
everything work in overlay |
| 23 |
but there is either no technical or bureaucracy reasons that prevent |
| 24 |
from fixing as soon as |
| 25 |
possible. |
| 26 |
|
| 27 |
All above is applicable because in overlay we work on programmers |
| 28 |
libraries, with enduser |
| 29 |
applications (that are synchronized with portage tree) situation is |
| 30 |
slightly different. |
| 31 |
|
| 32 |
-- |
| 33 |
Alexander |
Archives