On 11/01/2011 12:07 PM, Daniel Fischer wrote:

On Tuesday 01 November 2011, 11:50:45, Hugo Ferreira wrote:

...

Hello,

Recently I had to update and install a newer version of a library. I executed the "cabal update", which downloads the latest package list. I had assumed that this command would also detect, build and install those libraries that have been upgraded. However this does not seem to be the case. I had to manually build the library and then use GHC's package manager do unregister the old version.

Unregistering the old version is not necessary, different versions of the same package can coexist. However, if some of the installed packages depend on the old version and some on the newer, those packages can generally not be used together, so unregistering is safer.

Ok.

...

My question is: how does one check for and upgrade the cabal libraries automatically?

Not.

1. It's not possible to do it automatically since the latest versions of some packages can have incompatible dependencies, e.g. the latest foo depends on bar>= x.y&& < x.(y+1), the latest baz however depends on bar

...

= x.(y+1).

Then you can't have foo together with the latest baz.

2. Usually, some not-updated packages depend on updated packages. Even if no incompatibility as above is introduced, that would cause a *lot* of recompilation and reinstallation. You don't inflict that on users unless they explicitly ask for it.

3. Often there's no real point in upgrading packages. Say the widely used package quux-x.y.z.d (think of something like text) had a typo in the haddocks, author fixes and uploads quux-x.y.z.e; thanks for recompiling my entire set of installed packages. Or a minor addition to the API that you don't need. Or a fix in a CPP macro that doesn't affect you, ...

Installation of newer versions of packages you already have should be a conscious decision by you, after pondering the consequences.

I must confess I am a little disappointed. :-( I have used Ocaml + the GODI "package manager" and it seems work ok. GODI allows one to identify newer packages, select those we want to upgrade and recompiles any dependencies automatically. Thanks for the info. Hugo F.

On Wed, Nov 2, 2011 at 1:31 AM, Giovanni Tirloni wrote:

On Tue, Nov 1, 2011 at 2:04 PM, Hugo Ferreira wrote:

...

I have used Ocaml + the GODI "package manager" and it seems work ok. GODI allows one to identify newer packages, select those we want to upgrade and recompiles any dependencies automatically.

As a newcommer, I feel that this subject has already been discussed at length by the Haskell community and progress is being made.

Two articles that I have been referred to in order to understand it better:

http://www.vex.net/~trebla/haskell/sicp.xhtml#unsafeInterleave

http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-...

Thanks for those links.

As a Fedora user, I'm relying on the Haskell SIG work and using the ghc-* RPM packages. When a given Hackage package has not been packaged in Fedora yet, I'm using cabal to supplement but I think that's sub-optimal (from a sysadmin perspective). I'm looking at ways to actually build my own RPMs following their standards. As it's mentioned in one of the article, someone has had the trouble to figure out which packages work best together.

I wonder if you could throw some light on this? Say you just have to use the 'sub-optimal' solution and cabal install some package foo. Later it appears in the rpm list and you can yum install it. How do you now cabal uninstall foo?

I second Daniel's opinion that updates should be a conscious decision on the part of the developer. The kind of dependency problems exemplified are not restricted to cabal and apply as well to PHP's Pear, Perl's CPAN and others. What I usually see is that developers try to guarantee their packages will correctly work with a given set of dependencies and so they specify minimum and maximum versions of those as restrictions. Obviously, easing those restrictions would ensure it's easier to match package but who guarantees they'll work (i.e. no important API change) ?

My own experience managing packages in PHP hosting environments tells me that, even though the package manager was happy to upgrade everything I told it to.. I would usually find the interfacing problems myself in the form of downtime. In that scenario, I would prefer both a package more strictly defined in terms of dependencies. In cabal/Haskell things won't even compile, which is good :-)

Any, just 0.02 from a newbie.

Giovanni

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Fri, Nov 4, 2011 at 6:30 PM, Giovanni Tirloni wrote:

On Wed, Nov 2, 2011 at 1:05 AM, Rustom Mody wrote:

...

I wonder if you could throw some light on this? Say you just have to use the 'sub-optimal' solution and cabal install some package foo. Later it appears in the rpm list and you can yum install it. How do you now cabal uninstall foo?

I don't know if this is the "right way" but it seems to work: ghc-pkg unregister <package> rm  the contents from $HOME/.cabal/package/hackage.haskell.org/<package>

Maybe 'cab' on Hackage is the right thing to try. -- Yucheng Zhang