It appears that the "--global" option to ghc-pkg causes the program to
forget all of the preceding package configuration options.

Here we get results for all three options:

$ /usr/bin/ghc-pkg list  --global --user --package-conf=testp.conf
/usr/lib/ghc-6.4/package.conf:
...
    (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0)
/home/frederik/.ghc/i386-linux-6.4/package.conf:
testp.conf:
    WashNG-2.4.6-ng

Now --global screens --user:

$ /usr/bin/ghc-pkg list --user --global --package-conf=testp.conf
/usr/lib/ghc-6.4/package.conf:
...
    (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0)
testp.conf:
    WashNG-2.4.6-ng

Now --global screens everything:

$ /usr/bin/ghc-pkg list --user --package-conf=testp.conf  --global
/usr/lib/ghc-6.4/package.conf:
...
    (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0)

The following illustrates that --user does not have the same drawback:

$ /usr/bin/ghc-pkg list  --package-conf=testp.conf  --user
/usr/lib/ghc-6.4/package.conf:
...
    (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0)
/home/frederik/.ghc/i386-linux-6.4/package.conf:
testp.conf:
    WashNG-2.4.6-ng

This is very confusing, and not very useful!

I would suggest the following modification:

1. --global should behave just like --user and --package-conf, i.e. it
should augment rather than reset the current list of package
databases.

And either:

2a. There should be a --no-global option which causes the global
package.conf not to be included by default. Thus --global only has an
effect when --no-global has been specified. This is messy, but will
preserve behavior which is relied upon by Cabal, etc.

-or-

2b. The global package database should only be included by default
when no --package-conf or --user option is present. Otherwise, the
global package database should not be automatically included; --global
must be specified to include it. This will probably break some things
which assume that e.g. "ghc-pkg list --user" will include global
packages as well.


Both of these solutions are kind of messy. It's too bad that the
present system has come so far with these issues unaddressed, but now
I imagine that backwards compatibility is a concern.

Also, I would suggest that:

3. ghc, ghci, ghc-pkg, etc. should respond to an environment variable
GHC_PKG_PATH which contains a colon-separated list of package
databases, to be included as if they had been specified on the
command-line with --package-conf or -package-conf.

This would allow one to create environments consisting of different
sets of packages, without creating new users or buying new computers
to host them. Such is a feature of every other major compiler or
interpreter in existence.

Frederik

-- 
http://ofb.net/~frederik/
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to