вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky <m...@gentoo.org>: > But please quit looking to Go as an example of anything > anyone should be doing.
On a somewhat related note, I'd like to take this chance to ask about packaging haskell software, which has somewhat similar issues: 1. Two different executables might depend on different versions of a library. This is, of course, solvable via slots, so this is minor (but, looking at a random sample of `dev-haskell/`, most of libs there aren't slotted). 2. The dependency trees are pretty big and wide. A simple project of mine depends on a hundred or two of dependencies on average, and the union of all deps of all the projects I do is probably closer to a thousand. Again, this is minor, just bear in mind the corresponding ebuilds tree size increase. 3. What is major is the following. Let's say two executables A and B depend on libfoo:1 and libfoo:2 respectively, and depend on the same version of libbar. libbar itself depends on libfoo (and supports both versions), but libbar built with libfoo:1 is incompatible with libbar built with libfoo:2. Loosely speaking, the slot of a library is defined by all its dependencies' _versions_. Of all these, (3) is quite major, as it leads to exponential explosion of the slots count. Otherwise, one might choose to carefully curate the library versions, ensuring that no such situation arises, but this approach is neither feasible nor possible at all for sufficiently large packages base. In practice, outside of Gentoo/system PM issues, this does not pose a problem since each executable is built in an isolated sandbox and links statically to its dependencies, so different executables can happily be deployed alongside each other even if they have incompatible dependencies. But looks like Gentoo's approach to haskell is to use dynamic linking and expose the dependencies to the package manager (which I sure agree is the right thing to do), so what should be right the solution here? -- Georg Rudoy
