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