well, the first and most immediate problem is that I can not even fetch the package from hackage using cabal: # cabal fetch plugins Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 so, although I believe the problem with different versions of the same package to co-exist on my computer may be ignored in mane cases, this case makes life very inconvenient. -- Valentyn On Feb 1, 2009, at 1:57 AM, Marc Weber wrote:

...

Any suggestions?

a) ignore it and hope you don't get segfaults or problems.

b) choose one process libraries and rebuild the other packages using that one.

About a) I'm not totally sure what could happen. I just can say That i've used different cabal versions and it went fine. I guess that the problem is

A using P-1.0 B using P-1.2

you using A and B, passing data indirectly from A to B and A and B having different compilation options or different behaviour. I'm not too sure about this. Maybe this can give you an idea what could happen. On the other hand you do use runXY or system from process only without passing data from one to the other so chances are good that your app will work nevertheless.

Marc Weber _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

So, in practical terms, you suggest that no new version of the package that ghc package depends on (directly or indirectly) should ever be installed? For example, as soon as process-1.0.1.1 is installed on my computer, I'll have this problem with every package that depends on "process"? Another question: would not cabal-install automatically fetch the most recent version of the "process" package, as soon as I will try to install a package that depends on it (such as, for example, "plugins")? -- Valentyn. On Feb 1, 2009, at 6:53 AM, Duncan Coutts wrote:

On Sun, 2009-02-01 at 01:33 -0800, Valentyn Kamyshenko wrote:

...

Hello all,

when I tried to install plugins package with cabal, I've got the following error:

# sudo cabal install plugins --global Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0

For the most part I refer you to:

http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html

However the difference is that you've got this problem only within the global package db rather than due to overlap in the global and user package db.

...

It looks like both versions of process package are currently required:

It looks like you installed process-1.0.1.1 and then rebuilt almost every other package against it. Of course you cannot rebuild the ghc package but you did rebuild some of its dependencies which is why it now depends on multiple versions of the process package.

Generally rebuilding a package without also rebuilding the packages that depend on it is a bit dodgy (it can lead to linker errors or segfaults). Unfortunately cabal-install does not prevent you from shooting yourself in the foot in these circumstances.

...

Any suggestions?

Aim for a situation where you only have one version of the various core packages. If you do not need to install packages globally then installing them per-user means you at least cannot break the global packages.

Duncan

Duncan Coutts wrote:

That is probably how people are getting into this mess. Using upgrade is not necessarily such a good idea. It does not distinguish between the interesting packages you might want to upgrade and the core packages that your probably do not want to touch.

There's no need to use cabal upgrade to get into this kind of mess, I successfully pulled conflicting cabal versions just by using cabal install. -- (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.

Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? -- Valentyn. On Feb 2, 2009, at 5:34 PM, Duncan Coutts wrote:

On Tue, 2009-02-03 at 02:11 +0100, Achim Schneider wrote:

...

Duncan Coutts wrote:

...

That is probably how people are getting into this mess. Using upgrade is not necessarily such a good idea. It does not distinguish between the interesting packages you might want to upgrade and the core packages that your probably do not want to touch.

There's no need to use cabal upgrade to get into this kind of mess, I successfully pulled conflicting cabal versions just by using cabal install.

Indeed, it's just easier to shoot yourself in the foot using upgrade.

Would anyone object if I disable the upgrade command in the next version and not re-enable it until it works?

Duncan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Duncan, I agree with your arguments. I think it is a less evil to disable 'cabal upgrade' until the problem is fixed. To have 'cabal upgrade' to ask for confirmation (and to allow user to select packages to be updated from the list) is even better. -- Valentyn. On Feb 3, 2009, at 2:04 AM, Duncan Coutts wrote:

On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote:

...

Hi Duncan,

The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages).

Right, that's exactly what doesn't work well and that I'm proposing to temporarily disable.

...

I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal.

And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)?

Yes and there are a couple of additional ways we could improve it. But I'm thinking it'd be better to release before those things are done, and so in the mean time disable upgrade. In the mean time we can make it list the available packages that are newer than the installed ones and you get to pick manually which ones are sensible to install.

Duncan