
Edward Middleton
Achim Schneider wrote:
Edward Middleton
wrote: ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the world prevents there being some other program called ghc that would also like to be there. Only by painstaking verification of a whole bunch of applications together can one be confident of "safety". Well then I guess we agree, so the question becomes who should do the painstaking verification. I think distribution maintainers should do this, you think end users who can't compile source packages should do this.
Not the maintainers, but the tool. Portage doesn't install stuff if it would overwrite other things, records changes to files in e.g. /etc to be merged later (interactively, with diffs), and records every file it ever installed by having the package install itself in /var/portage/<package>/<version>. You are _completely_busted_ if your install script doesn't support that: The script runs sandboxed.
Portage even registers every installed package into an empty ghc package database, and merges them later. It knows what it does.
I can switch between different versions of packages, or different implementations of the same functionality (say, java-sun vs. java-blackdown) with eselect.
In short: Don't write your own install scripts, you're bound to get it wrong, and/or be vastly inferior, compared to portage.
But who writes the ebuild[1] ? That said, on the various system I run I have over 100 custom ebuilds that I maintain. I can do this because most applications have standard sane build systems that install things in the regular places.
Yes, usually it's just a matter of writing "inherit distutils" and figuring out (still missing) dependencies. While I utterly loathe autoconf, it has its merit... being widely used. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.