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