On Fri, Mar 01, 2013 at 05:13:58PM +0100, Jan Stolarek wrote:
There's one big difference here: rpm/dpkg are only used to install things by the system administrator. But in the case of Cabal, a user could install 'mypackage' (in their user package database) and the next day the sysadmin could install a different instance of 'mypackage' in the global database. Then we must come up with a way of handling such a situation. The first idea that comes to my head is that by default cabal would only use one database: either the global one managed by the system administrator or the local user database.
Well, that basically means you can't use the local one, as base is in the global one. Even if you made it a 3 database system: * the 'ghc' database, containing base, directory, etc * the 'system' database, containing and packages from Debian (for example) * the 'user' database, containing things you install where you have the choice of (ghc + system) or (ghc + user) then that means that you can only use packages from your OS if every single package you want to use is packaged by the OS. You could imagine changing things so that packages installed by OS packages aren't actually visible, and there's some way to add them to your user database (provided that would keep everything consistent). Perhaps 'cabal install foo' would first check to see if there is a suitable 'global' foo that it can just register in its database. It would be a more klunky workflow, but perhaps better than the status quo. Thanks Ian