[Haskell-cafe] Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`

[Joachim Durchholz]

Am 29.11.2015 um 21:46 schrieb Michael Orlitzky:
> On 11/29/2015 02:39 PM, Omari Norman wrote:
>>
>> So there's a distribution out there where end users pull source from
>> Hackage, pull source for every dependency, and then build it all with
>> GHC?  If they're not doing what distributors like Debian does--building
>> binaries--then what's the point of distributing at all?
>
> Sure, all of the source-based distributions use the upstream tarball and
> compile it. The point of creating a "package" is so that you can have a
> real package manager manage your dependencies. Since most of the
> dependency info is contained in the cabal file, the packages are usually
> trivial. Gentoo, Nix, and FreeBSD all have tools that will convert a
> hackage package into a distribution package automatically.
>
>
>>      When using a real package manager, every package's dependencies must be
>>      satisfied simultaneously.
>>
>>
>> True, but ouch, ultimately this is one factor that pushed me out of
>> desktop Linux altogether.  It's too hard to get packages for things I
>> want to use, and then I'm fending for myself by building things.
>> Centrally-planned packaging does not scale.
>
> Given that almost all Linux systems in existence uses centrally-planned
> packaging, I don't believe that last claim.

What does not scale is having to beg, bribe, or strong-arm upstreams 
into using a consistent set of library versions. You'll run into 
situation where application A wants libraries X.5 and Y.6, and 
application B wants X.6 and Y.4, and at that point, you'll have to make 
a hard decision between A and B.

One way out is to make it so that multiple versions of the same library 
can be installed at the same time. C-based packages do this routinely by 
installing not libX and libY, but by installing libX-5, libX-6, libY.4, 
and libY.6. This still requires a mechanism to automatically select the 
right packaged lib, so the Haskell runtime will have to be told which 
libraries at what versions to combine with a given application. This 
could be totally easy or a huge PITA, I don't know enough about Haskell 
(I just happen to have a lot of administration experience with Linux).

Another way out is to statically link each application, and avoid 
library packages entirely. It's viable only because we have 
multi-terabyte harddisks and multi-gigabyte RAM these days, and probably 
not what everybody wants to do.

One thing that does not work at all in my experience is situations where 
you have a software ecosystem that's orthogonal to the OS. Typical 
package managers offer no way of having a local install, so my Eclipse 
installation typically consists of a download somewhere into my home 
directory, and plugins installed into that. Python is similar - I almost 
never install a Python application directly, I download it, use a 
virtualenv (Python's sandboxing method), and let it pull in and set up 
any dependencies it wants or needs.
These local installs are all wheel reinventions, it would be better if 
apt, yum, rpm etc. supported local installs (in the form of "please 
install this into THAT directory inside my home dir, thank you very 
much"), and kept these installs separate. You can do stuff like that, 
but it requires expert knowledge so it's not an option for application 
installs.

 > How many programs can you
> realistically keep installed and up-to-date with stack? Ten, twenty
> maybe -- if this is a serious hobby for you. One or two hundred if it's
> your full-time job?
>
> A typical Linux system will have hundreds of packages, and a system
> administrator will need to manage tens or hundreds of those systems.
> It's just not possible to do with something like stack -- you need one
> package manager that does everything.

True for operating systems. Or anything else that needs to "just work" 
without bothering about specific versions.
Not so true for those individual applications. Of these, you often need 
a specific version, and since nothing in the OS depends on them, it's 
okay to have these installed independently of the package manager (but 
these applications can have such complicated dependency setups that 
they'll need their own package managers - Eclipse and Python come with 
such things for exactly that reason).

Regards,
Jo