Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

[Michael Orlitzky]

On 4/20/20 4:21 PM, Georg Rudoy wrote:
> вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky <mjo@g.o>:
>>  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:
>
> ...
> 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.

There's nothing Haskell-specific here, is there? Except that Haskell as
a research language tends to inspire more "fire and forget" software.
(And Haskell works better in Gentoo than anywhere else, in my opinion.)

You package each dependency as a separate package. If there's a conflict
between two packages, then... you can't have those two packages
installed together. When that happens, you alert upstream, and try to
convince them to be more lenient with their dependencies (again, nothing
Haskell-specific here). Sometimes that involves code changes, but often
it's just an edit to the cabal file. Many people follow either semver or
the PVP (https://pvp.haskell.org/) which keeps things from getting too
far out of control.

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.

Software engineering is a fractal. Curating APIs and dependencies is as
much a part of it as what sorting algorithms you choose. These are all
old problems with known solutions (sonames, semver, etc.) and software
isn't magically high-quality because it's written in a language that
came our last week.

So aside from the "What's Gentoo?" that's going to be more common among
Haskell upstreams, I don't see anything fundamentally different here
between Haskell (or Go, or...) and C. We should be helping to make
upstream software more good, and then packaging it. (It's OK to hack the
cabal file while the bug report is open.)