| 1 |
Hi, |
| 2 |
|
| 3 |
On Sat, 18 Jul 2015 21:24:13 +0100 Sergei Trofimovich wrote: |
| 4 |
> As you have discovered haskell packages have deep dependency chains |
| 5 |
> and are interdependent. We (the haskell team) don't have a good stabilization |
| 6 |
> story at all. |
| 7 |
> |
| 8 |
> It's partly why you didn't get any response. |
| 9 |
> |
| 10 |
> Our plan used to be "stabilize new major GHC on all arches and fix |
| 11 |
> what breaks afterwards". We've improved our ebuild generation |
| 12 |
> since thus you get resolution-time conflicts instead of compile-time |
| 13 |
> ones. |
| 14 |
> |
| 15 |
> To ease the STABLEREQ pain we need: |
| 16 |
> - stabilize stuff more argressively (needs some tooling), that |
| 17 |
> will solve dependency depth problem on every new stabilization |
| 18 |
> - fix repoman to help us in at least detecting inconsistent states: |
| 19 |
> https://bugs.gentoo.org/show_bug.cgi?id=555266 |
| 20 |
> that way we will gain more confidence f stable tree not being |
| 21 |
> completely broken |
| 22 |
|
| 23 |
Looks like this problem is not only haskell related, but concerns |
| 24 |
all projects which support languages with high atomicity of |
| 25 |
language modules, tools or extensions. While I respect such |
| 26 |
atomicity as following Unix-way deeply, I must admit that it should |
| 27 |
create a lot of pain during maintenance of such projects. |
| 28 |
|
| 29 |
Aside from haskell on my mind comes perl, TeX, octave, Go. Probably |
| 30 |
many others I can't remember right now. |
| 31 |
|
| 32 |
Looks like we need some toolkit to mass-handle ebuilds like |
| 33 |
generation, version bumps, dependency and consistency checks. |
| 34 |
We already have g-sorcery and other g-* projects. I'm not sure if |
| 35 |
haskell uses one. Anyway having mass-updater and consistency |
| 36 |
checker as a complementary to these tools will be great. |
| 37 |
|
| 38 |
Best regards, |
| 39 |
Andrew Savchenko |
Archives