On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
> Why should portage download some outdated second copy of the
> sources for 'bar', rebuild it, and scatter it around the file system
> where it cannot be used by other programs installed by cabal?

These other package managers don't solve any hard problems -- they're
basically a fancy interface around wget and "git clone." Portage on the
other hand has ~20 years of good ideas and hard work on the hard
problems in package management. For example...

> It seems reasonable to me to 'hook' portage into these other package
> managers, so that running 'emerge bar' would actually run 'cabal install
> bar'

Can "cabal install" build or even identify the C libraries that your
Haskell package needs? No, because nobody ever thought of that, and it
seems kind of hard now that the cabal build system has no ability to
build non-Haskell packages, so no one is ever going to work on it.

Can "cabal install" rebuild your Haskell packages when the ABI of some
library changes? No, because "cabal install" doesn't have any idea
what's installed on your system.

Can "cabal install" uninstall a package? Nope, it has no idea what was
done during the installation, and thus no idea what to undo.

Can "cabal install" verify the integrity of your downloaded source code?
No, because by design it fetches and runs code from complete strangers.

Can "cabal install" use a local tarball to function without network
access? Etc. We're dead in the water.

Every other language-specific package manager has the same problems,
because they're all written by people who didn't know anything about
package management and then got bored when they realized that there's
more to it than parsing a json file of dependencies.

If you want to eliminate the duplication of effort, tell these people to
use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the
other way around won't work because we'd be replacing one good thing
with 75 shitty things.

Reply via email to