| 1 |
On 4/20/20 5:05 PM, Georg Rudoy wrote: |
| 2 |
> |
| 3 |
>> If upstream absolutely insists on minor-version dependencies, then you |
| 4 |
>> either tolerate it conflicting with everything else, or leave it out of |
| 5 |
>> the tree. You probably shouldn't even be packaging a library whose API |
| 6 |
>> is distinguishable across minor releases. |
| 7 |
> |
| 8 |
> That's not a matter of just the API per se. Even the library file name |
| 9 |
> encodes its deps in its name (if I understand correctly, that's the |
| 10 |
> hash in libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so |
| 11 |
> for example). Personally I just find it hard to reason about this sort |
| 12 |
> of dependencies management. But, again, I should probably avoid trying |
| 13 |
> that and just jump head first to packaging. |
| 14 |
|
| 15 |
Haskell already requires transitive rebuilds of dependencies due to a |
| 16 |
(serious) implementation constraint. Subslots help with that, but it |
| 17 |
will take a new EAPI to truly tell an ebuild how to do what we need to |
| 18 |
do. In any case, all Haskell ebuilds depend on separate packages for |
| 19 |
their dependencies, and with haskell-updater, subslots, and |
| 20 |
@preserved-rebuild it all more or less works. |
| 21 |
|
| 22 |
I think that's largely separate from the "diamond dependency problem" |
| 23 |
you posed. Diamond dependencies manifest mainly in delayed version |
| 24 |
bumps, while slyfox does all the work to make sure that the things |
| 25 |
already in the tree will work with the new version. This requires lots |
| 26 |
of careful updates to neighboring packages, and unfortunately a lot of |
| 27 |
cabal file hacking. |
| 28 |
|
| 29 |
|
| 30 |
> Dunno much about Go and I don't have a single Go package locally to |
| 31 |
> check. Do they do static or dynamic linking with the deps, for |
| 32 |
> instance? What's the language model wrt API and linking? |
| 33 |
|
| 34 |
FORGET I MENTIONED IT |
| 35 |
|
| 36 |
|
| 37 |
>> and C. |
| 38 |
> |
| 39 |
> More stable API (and ABI). |
| 40 |
> |
| 41 |
|
| 42 |
Definitely. The "Haskell" language changes entirely every few years. |
| 43 |
I've learned the hard way that it discourages you from doing all the |
| 44 |
things that I just said high-quality software should do. |
| 45 |
|
| 46 |
There's a core of mature Haskell that's pretty easy to develop against. |
| 47 |
(I think you just have to wait about five years with any project before |
| 48 |
the authors realize that changing everything every month isn't fun.) Out |
| 49 |
in the woods you can still get into a lot of trouble though. We now have |
| 50 |
the mature core stuff in ::gentoo, and the crazies out in the ::haskell |
| 51 |
overlay. That feels like the right mix. |
Archives