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