[Haskell-cafe] Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`
jo at durchholz.org
Sun Nov 29 21:19:47 UTC 2015
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
> 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).
More information about the Haskell-Cafe