Re: [arch-haskell] help upgrading packages

[Bardur Arantsson]

On 2014-05-15 23:18, Magnus Therning wrote:
> On Thu, May 15, 2014 at 05:29:13PM +0200, Bardur Arantsson wrote:
>> On 2014-05-15 11:35, Magnus Therning wrote:
>>> On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson  
>>> wrote:
 On 2014-05-12 15:47, Magnus Therning wrote:
 [--snip--]

 All I needed to install build-wrapper (which I think was the
 inital "problem" package in this thread) was to do

 $ mkdir somewhere/buildwrapper
 $ cd somewhere/buildwrapper
 $ cabal sandbox init
 $ cabal install buildwrapper

 Add "somewhere/buildwrapper" to $PATH. Bonus points for using
 "stow" or similar.
 The key point in the above recipe is to *NOT* have all kinds of
 libraries installed system-wide (aka. via pacman). It usually
 works better that way.
>>>
>>> Surely you should then `cabal install` the tool so you don't end up
>>> with a complete sandbox with every dependency of buildwrapper's in
>>> it, no?
>>
>> You *do* need to keep the sandbox around (or at least parts of it).
>> That's where the last "cabal install" line installs to.
> 
> Well, wouldn't you want the binary installed somewhere else, so you
> don't need to keep the sandbox around?  Or do you build all your
> haskell tools (hlint, hoogle, buildwrapper, hasktags, ghc-mod, etc) in
> the same sandbox?
> 

What I do for executable-only is pretty simple. I use stow to manage all
non-distro software that I install, so I have one directory
per package, like so:

  ~/stow/ghc-mod/lib/ghc-mod/src
  ~/stow/hums/lib/hums/src
  (etc.)

Each of these directories contains a full sandbox with a locally-run
"cabal install".

For each package I add a "bin" directory, so

 ~/stow/ghc-mod/bin

and put in the necessary relative symlinks:

 ~/stow/ghc-mod-4.0.2/bin
cpphs -> ../lib/ghc-mod/.cabal-sandbox/bin/cpphs
ghc-mod -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-mod
ghc-modi -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-modi
hlint -> ../lib/ghc-mod/.cabal-sandbox/bin/hlint
HsColour -> ../lib/ghc-mod/.cabal-sandbox/bin/HsColour

And finally use stow to "merge" the package into my ~ directory, so that
all the bin/ symlinks end up in my ~/bin.

(I use stow because I'm pretty pendantic about keeping "packages"
separate from everything else in my $HOME, but you could also just have
a ~/src with a sandbox for every package and add symlinks directly from
your ~/bin into the sandboxes. It's just that since all my non-haskell
non-distro self-built software is managed by stow, I chose to also use
stow for this.)

>>> For some packages you would have to keep the sandbox around and do
>>> it your way though, e.g. `pandoc` since it contains both a library
>>> and executables.
>>
>> If you want to use a sandboxed thing as a library then you need to
>> develop "inside" the sandbox, so e.g. you'd just create a little
>> cabal file for your project which declares all the dependencies and
>> use cabal to build your project.
> 
> That's indeed the case, but that's *not* the point I was trying to
> make.  If a package only consists of executables you can use the
> `install` target of the Cabal file to install them.  If a package
> consists of both a library and executables it's more manual work.

I think we might be talking past each other...

I'm afraid I don't understand what you mean by "more manual work". Using
sandboxes the way I've described above doesn't really work at all for
executable + library situations. (So I offered a different solution to
that problem, namely cabal-ifying your own package that depends on a
library and installing your own package in a sandbox.)

>> Cabal also works beautifully for "hobby" type development. Once
>> you've created a cabal file you hardly ever need to touch it again.
>> :)
> 
> But it's overkill.  Do keep in mind that Cabal and `cabal` are two
> different things.  Of course I use Cabal in all my packages, but I
> don't use `cabal` at all.  The main reason I see for using `cabal`
> would be when I need to maintain compatibility with multiple versions
> of GHC and or packages I depend on.
> 

If we want to get pendantic, it's probably best to say Cabal vs.
cabal-install (which is where the "cabal" executable comes from, for
those who don't know).

I use cabal-install for all development with a .cabal file for each of
my projects, I never use Cabal (the library) directly as I've never
encountered a need to. I've not encountered many packages which use
anything other than the standard boilerplate Setup.hs/Setup.lhs file.
(Some packages with *really* complex build requirements do so, e.g.
Gtk2hs, but I assumed that's not quite the level of complexity we're
talking here.)

Anyway, enough rambling on...

Regards,

___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Magnus Therning]

On Thu, May 15, 2014 at 05:29:13PM +0200, Bardur Arantsson wrote:
> On 2014-05-15 11:35, Magnus Therning wrote:
>> On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson  
>> wrote:
>>> On 2014-05-12 15:47, Magnus Therning wrote:
>>> [--snip--]
>>>
>>> All I needed to install build-wrapper (which I think was the
>>> inital "problem" package in this thread) was to do
>>>
>>> $ mkdir somewhere/buildwrapper
>>> $ cd somewhere/buildwrapper
>>> $ cabal sandbox init
>>> $ cabal install buildwrapper
>>>
>>> Add "somewhere/buildwrapper" to $PATH. Bonus points for using
>>> "stow" or similar.
>>> The key point in the above recipe is to *NOT* have all kinds of
>>> libraries installed system-wide (aka. via pacman). It usually
>>> works better that way.
>> 
>> Surely you should then `cabal install` the tool so you don't end up
>> with a complete sandbox with every dependency of buildwrapper's in
>> it, no?
> 
> You *do* need to keep the sandbox around (or at least parts of it).
> That's where the last "cabal install" line installs to.

Well, wouldn't you want the binary installed somewhere else, so you
don't need to keep the sandbox around?  Or do you build all your
haskell tools (hlint, hoogle, buildwrapper, hasktags, ghc-mod, etc) in
the same sandbox?

>> For some packages you would have to keep the sandbox around and do
>> it your way though, e.g. `pandoc` since it contains both a library
>> and executables.
> 
> If you want to use a sandboxed thing as a library then you need to
> develop "inside" the sandbox, so e.g. you'd just create a little
> cabal file for your project which declares all the dependencies and
> use cabal to build your project.

That's indeed the case, but that's *not* the point I was trying to
make.  If a package only consists of executables you can use the
`install` target of the Cabal file to install them.  If a package
consists of both a library and executables it's more manual work.

>>> Disclaimer: I haven't actually used buildwrapper personally, but
>>> one assumes that it just acts as an executable and doesn't install
>>> things into its own environment or other weird things.
>> 
>> Personally I think `cabal` really shines when doing more serious
>> Haskell development than I do.  I never test my Haskell packages on
>> anything other than the GHC that's in [haskell-core], and neither
>> do I test them against any other versions of packages than what's
>> found in [haskell-core].  My Haskell development is completely in
>> my free time and for fun.  I think that if I ever am lucky enough
>> find myself using Haskell professionally I'd quickly see more use
>> in what `cabal` has to offer.
> 
> Cabal also works beautifully for "hobby" type development. Once
> you've created a cabal file you hardly ever need to touch it again.
> :)

But it's overkill.  Do keep in mind that Cabal and `cabal` are two
different things.  Of course I use Cabal in all my packages, but I
don't use `cabal` at all.  The main reason I see for using `cabal`
would be when I need to maintain compatibility with multiple versions
of GHC and or packages I depend on.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

What gets measured, gets done.
 -- Tom Peters


pgpL8EJJFLR59.pgp
Description: PGP signature
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Bardur Arantsson]

On 2014-05-15 11:35, Magnus Therning wrote:
> On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson  
> wrote:
>> On 2014-05-12 15:47, Magnus Therning wrote:
>> [--snip--]
>>
>> All I needed to install build-wrapper (which I think was the inital
>> "problem" package in this thread) was to do
>>
>> $ mkdir somewhere/buildwrapper
>> $ cd somewhere/buildwrapper
>> $ cabal sandbox init
>> $ cabal install buildwrapper
>>
>> Add "somewhere/buildwrapper" to $PATH. Bonus points for using "stow" or
>> similar.
>> The key point in the above recipe is to *NOT* have all kinds of
>> libraries installed system-wide (aka. via pacman). It usually works
>> better that way.
> 
> Surely you should then `cabal install` the tool so you don't end up
> with a complete sandbox with every dependency of buildwrapper's in it,
> no?
> 

You *do* need to keep the sandbox around (or at least parts of it).
That's where the last "cabal install" line installs to.

> For some packages you would have to keep the sandbox around and do it
> your way though, e.g. `pandoc` since it contains both a library and
> executables.
> 

If you want to use a sandboxed thing as a library then you need to
develop "inside" the sandbox, so e.g. you'd just create a little cabal
file for your project which declares all the dependencies and use cabal
to build your project.

>> Disclaimer: I haven't actually used buildwrapper personally, but one
>> assumes that it just acts as an executable and doesn't install things
>> into its own environment or other weird things.
> 
> Personally I think `cabal` really shines when doing more serious
> Haskell development than I do.  I never test my Haskell packages on
> anything other than the GHC that's in [haskell-core], and neither do I
> test them against any other versions of packages than what's found in
> [haskell-core].  My Haskell development is completely in my free time
> and for fun.  I think that if I ever am lucky enough find myself using
> Haskell professionally I'd quickly see more use in what `cabal` has to
> offer.
> 

Cabal also works beautifully for "hobby" type development. Once you've
created a cabal file you hardly ever need to touch it again. :)

Regards,

___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Magnus Therning]

On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson  wrote:
> On 2014-05-12 15:47, Magnus Therning wrote:
> [--snip--]
>> The same goes for me.  Occasionally I revert to installing a package
>> for the local user only, but not even then do I use `cabal install` to
>> do that, I prefer running `./Setup.hs configure,build,install` myself.
>>
>> I do mean to look into using `cabal` myself at some point, because I
>> keep on hearing good things about it.  So far every time I've tried it
>> I've run into something weird, most recently it was trying to install
>> an older version of a lib than was needed, and I already had the newer
>> version installed on my system too.  A lot of terrifyingly clever
>> people swear by it though, so there has to be something I'm missing
>> out on!
>
> Gah! Just try it!
>
> All I needed to install build-wrapper (which I think was the inital
> "problem" package in this thread) was to do
>
> $ mkdir somewhere/buildwrapper
> $ cd somewhere/buildwrapper
> $ cabal sandbox init
> $ cabal install buildwrapper
>
> Add "somewhere/buildwrapper" to $PATH. Bonus points for using "stow" or
> similar.
> The key point in the above recipe is to *NOT* have all kinds of
> libraries installed system-wide (aka. via pacman). It usually works
> better that way.

Surely you should then `cabal install` the tool so you don't end up
with a complete sandbox with every dependency of buildwrapper's in it,
no?

For some packages you would have to keep the sandbox around and do it
your way though, e.g. `pandoc` since it contains both a library and
executables.

> Disclaimer: I haven't actually used buildwrapper personally, but one
> assumes that it just acts as an executable and doesn't install things
> into its own environment or other weird things.

Personally I think `cabal` really shines when doing more serious
Haskell development than I do.  I never test my Haskell packages on
anything other than the GHC that's in [haskell-core], and neither do I
test them against any other versions of packages than what's found in
[haskell-core].  My Haskell development is completely in my free time
and for fun.  I think that if I ever am lucky enough find myself using
Haskell professionally I'd quickly see more use in what `cabal` has to
offer.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Bardur Arantsson]

On 2014-05-12 15:47, Magnus Therning wrote:
[--snip--]
> The same goes for me.  Occasionally I revert to installing a package
> for the local user only, but not even then do I use `cabal install` to
> do that, I prefer running `./Setup.hs configure,build,install` myself.
> 
> I do mean to look into using `cabal` myself at some point, because I
> keep on hearing good things about it.  So far every time I've tried it
> I've run into something weird, most recently it was trying to install
> an older version of a lib than was needed, and I already had the newer
> version installed on my system too.  A lot of terrifyingly clever
> people swear by it though, so there has to be something I'm missing
> out on!

Gah! Just try it!

All I needed to install build-wrapper (which I think was the inital
"problem" package in this thread) was to do

$ mkdir somewhere/buildwrapper
$ cd somewhere/buildwrapper
$ cabal sandbox init
$ cabal install buildwrapper

Add "somewhere/buildwrapper" to $PATH. Bonus points for using "stow" or
similar.

The key point in the above recipe is to *NOT* have all kinds of
libraries installed system-wide (aka. via pacman). It usually works
better that way.

Disclaimer: I haven't actually used buildwrapper personally, but one
assumes that it just acts as an executable and doesn't install things
into its own environment or other weird things.

Regards,

___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Xyne]

On 2014-05-12 07:01 -0700
Michael Katelman wrote:

>Thanks, all! I ultimately did the same thing: removing and re-installing
>the entire Haskell ecosystem. It seems happy now :)
>
>-Mike

FYI, you can downgrade packages to match the current versions in the repo using

pacman -Syuu


For re-installing all of your haskell packages you may find two of my apps
useful: pkg-topological_reinstall and pkg-list_dependents. Both are included in
my pkg_scripts package [1].

The first was written specifically for dealing with GHC and will generate
scripts to remove GHC and all dependencies then re-install the explicitly
installed packages (with dep resolution). You can do more with it (e.g. add
intermediate steps) by tweaking the generated scripts (which are very simple).

The second app will simply list all dependents of a target package so that you
can create your own scripts.

[1] http://xyne.archlinux.ca/projects/pkg_scripts/

Regards,
Xyne
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Magnus Therning]

On Mon, May 12, 2014 at 4:02 PM, Dawid Loubser  wrote:
> I'm afraid that I am not one of those 'terrifyingly clever' people you speak
> of, Magnus, but in the past I have had a world of pain trying to use a
> mixture of packages between cabal and pacman.
>
> Had a very happy time using just pacman until haskell-buildwrapper
> disappeared recently, and I could no longer use my favourite Haskell IDE :-(
> I don't want to even try installing it using cabal, becuase then I'll be
> back in package-dependency hell.
>
> I have to say, I appreciate your efforts into making Haskell easy to use on
> Arch so very much - I don't mean to complain at all!

Create a new issue for it on the github page[1], or even better dig
into `cblrepo`, add it yourself, and send me a pull request ;)

/M

[1]: https://github.com/archhaskell/habs/issues

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Dawid Loubser]

I'm afraid that I am not one of those 'terrifyingly clever' people you
speak of, Magnus, but in the past I have had a world of pain trying to
use a mixture of packages between cabal and pacman.

Had a very happy time using just pacman until *haskell-buildwrapper*
disappeared recently, and I could no longer use my favourite Haskell IDE :-(
I don't want to even try installing it using cabal, becuase then I'll be
back in package-dependency hell.

I have to say, I appreciate your efforts into making Haskell easy to use
on Arch so very much - I don't mean to complain at all!

regards,
Dawid


On 12/05/2014 15:47, Magnus Therning wrote:
> On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini  wrote:
>> On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser 
>> wrote:
>>> I had a similar issue with a large number of packages.
>>> I ended up removing and re-installing my entire Haskell ecosystem, and now
>>> things work again.
>>>
>> Normally this should never happen. It's because Haskell is very strict on
>> dependencies (despite being lazy on other things).
>> In this case the reason was that those packages were added to the repository
>> [haskell-core] with initial release number set to 1, although they had been
>> in [haskell-happstack] already for some time and their release number was
>> higher. I removed those immediately from [haskell-happstack] to avoid
>> duplicate work, but they must also be manually removed from local, since
>> pacman always keeps the highest version-release.
>>
>> In order to avoid this kind of issues in the future we should either have a
>> policy to coordinate work between different haskell repositories, or merge
>> everything into a unique repository and call it simply [haskell].
> Indeed.  This is entirely my fault!
>
> I have not been keeping track of what is available in any other repos
> at all.  I was even under the impression that there were no other
> maintained repos at the moment.  Clearly I am completely wrong :(
>
>>> I note the absence of certain packages like haskell-buildwrapper (which
>>> EclipseFP tools needs) - and reading the wiki, it seems confusing at this
>>> time whether the Haskell tinkerer / developer should just be using
>>> cabal-install to install all required packages (even though I know that
>>> cabal is not a package management system) or... what?
>> Personally I don't like installing things using cabal-install because in my
>> opinion the distro package manager should always be in charge.
> The same goes for me.  Occasionally I revert to installing a package
> for the local user only, but not even then do I use `cabal install` to
> do that, I prefer running `./Setup.hs configure,build,install` myself.
>
> I do mean to look into using `cabal` myself at some point, because I
> keep on hearing good things about it.  So far every time I've tried it
> I've run into something weird, most recently it was trying to install
> an older version of a lib than was needed, and I already had the newer
> version installed on my system too.  A lot of terrifyingly clever
> people swear by it though, so there has to be something I'm missing
> out on!
>
> /M
>

___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Michael Katelman]

Thanks, all! I ultimately did the same thing: removing and re-installing
the entire Haskell ecosystem. It seems happy now :)

-Mike


On Mon, May 12, 2014 at 5:24 AM, Dawid Loubser wrote:

>  I had a similar issue with a large number of packages.
> I ended up removing and re-installing my entire Haskell ecosystem, and now
> things work again.
>
> I note the absence of certain packages like haskell-buildwrapper (which
> EclipseFP tools needs) - and reading the wiki, it seems confusing at this
> time whether the Haskell tinkerer / developer should just be using
> cabal-install to install all required packages (even though I know that
> cabal is not a package management system) or... what?
>
> What are other Haskell developers here doing currently?
>
> kind regards,
> Dawid Loubser
>
>
>
> On 12/05/2014 08:49, Nicola Squartini wrote:
>
> http-conduit and its dependencies moved from haskell-happstack to
> haskell-core and at that time the package release number reset to one. You
> have to manually uninstall and reinstall those packages.
>
>  Nicola
>
>
> On Sun, May 11, 2014 at 11:49 PM, Michael Katelman wrote:
>
>> I was hoping someone might help me with an issuing I'm having doing a
>> system upgrade. When I run pacman -Syu, I get:
>>
>>  :: Synchronizing package databases...
>> haskell-core is up to date
>> haskell-happstack is up to date
>> core is up to date
>> extra is up to date
>> community is up to date
>> :: Starting full system upgrade...
>> warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than
>> haskell-core (0.8.1.3-2)
>> warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core
>> (0.8.1-2)
>> warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core
>> (0.2.3-1)
>> warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core
>> (0.2.7-1)
>> warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core
>> (0.1.4-1)
>> warning: haskell-connection: local (0.2.1-3) is newer than haskell-core
>> (0.2.1-2)
>> warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core
>> (0.5.2-1)
>> warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than
>> haskell-core (0.0.9-1)
>> warning: haskell-crypto-numbers: local (0.2.3-3) is newer than
>> haskell-core (0.2.3-1)
>> warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than
>> haskell-core (0.2.4-1)
>> warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than
>> haskell-core (0.4.2.2-1)
>> warning: haskell-crypto-random: local (0.0.7-4) is newer than
>> haskell-core (0.0.7-1)
>> warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than
>> haskell-core (0.2.1.1-2)
>> warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core
>> (2.1.2-2)
>> warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core
>> (0.1.0.4-2)
>> warning: haskell-publicsuffixlist: local (0.1-7) is newer than
>> haskell-core (0.1-2)
>> warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core
>> (0.1.3-1)
>> warning: haskell-socks: local (0.5.4-10) is newer than haskell-core
>> (0.5.4-2)
>> warning: haskell-x509: local (1.4.11-5) is newer than haskell-core
>> (1.4.11-2)
>> warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core
>> (1.4.4-2)
>> warning: haskell-x509-validation: local (1.5.0-9) is newer than
>> haskell-core (1.5.0-2)
>> resolving dependencies...
>> looking for inter-conflicts...
>> error: failed to prepare transaction (could not satisfy dependencies)
>> :: haskell-connection: requires haskell-network=2.4.2.2-60
>> :: haskell-connection: requires haskell-tls=1.2.6-5
>> :: haskell-connection: requires haskell-x509=1.4.11-5
>> :: haskell-connection: requires haskell-x509-store=1.4.4-9
>> :: haskell-connection: requires haskell-x509-validation=1.5.0-9
>> :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59
>> :: haskell-cookie: requires haskell-text=1.1.1.1-1
>> :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3
>> :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4
>> :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2
>> :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60
>> :: haskell-http-client-tls: requires haskell-tls=1.2.6-5
>> :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1
>> :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2
>> :: haskell-http-conduit: requires haskell-http-types=0.8.4-4
>> :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3
>> :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5
>> :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1
>> :: haskell-socks: requires haskell-network=2.4.2.2-60
>> :: haskell-x509-system: requires haskell-x509=1.4.11-5
>> :: haskell-x509-system: requires haskell-x509-store=1.4.4-9
>>
>>
>>  I really have no idea what to do with this or what would have caused
>> it. I'm sure it's some important misunderstanding on my part. Any help
>> would be greatly apprec

Re: [arch-haskell] help upgrading packages

[Magnus Therning]

On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini  wrote:
> On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser 
> wrote:
>>
>> I had a similar issue with a large number of packages.
>> I ended up removing and re-installing my entire Haskell ecosystem, and now
>> things work again.
>>
> Normally this should never happen. It's because Haskell is very strict on
> dependencies (despite being lazy on other things).
> In this case the reason was that those packages were added to the repository
> [haskell-core] with initial release number set to 1, although they had been
> in [haskell-happstack] already for some time and their release number was
> higher. I removed those immediately from [haskell-happstack] to avoid
> duplicate work, but they must also be manually removed from local, since
> pacman always keeps the highest version-release.
>
> In order to avoid this kind of issues in the future we should either have a
> policy to coordinate work between different haskell repositories, or merge
> everything into a unique repository and call it simply [haskell].

Indeed.  This is entirely my fault!

I have not been keeping track of what is available in any other repos
at all.  I was even under the impression that there were no other
maintained repos at the moment.  Clearly I am completely wrong :(

>> I note the absence of certain packages like haskell-buildwrapper (which
>> EclipseFP tools needs) - and reading the wiki, it seems confusing at this
>> time whether the Haskell tinkerer / developer should just be using
>> cabal-install to install all required packages (even though I know that
>> cabal is not a package management system) or... what?
>
> Personally I don't like installing things using cabal-install because in my
> opinion the distro package manager should always be in charge.

The same goes for me.  Occasionally I revert to installing a package
for the local user only, but not even then do I use `cabal install` to
do that, I prefer running `./Setup.hs configure,build,install` myself.

I do mean to look into using `cabal` myself at some point, because I
keep on hearing good things about it.  So far every time I've tried it
I've run into something weird, most recently it was trying to install
an older version of a lib than was needed, and I already had the newer
version installed on my system too.  A lot of terrifyingly clever
people swear by it though, so there has to be something I'm missing
out on!

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell

Re: [arch-haskell] help upgrading packages

[Nicola Squartini]

On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser wrote:

>  I had a similar issue with a large number of packages.
> I ended up removing and re-installing my entire Haskell ecosystem, and now
> things work again.
>
> Normally this should never happen. It's because Haskell is very strict on
dependencies (despite being lazy on other things).
In this case the reason was that those packages were added to the
repository  [haskell-core] with initial release number set to 1, although
they had been in [haskell-happstack] already for some time and their
release number was higher. I removed those immediately
from [haskell-happstack] to avoid duplicate work, but they must also be
manually removed from local, since pacman always keeps the highest
version-release.

In order to avoid this kind of issues in the future we should either have a
policy to coordinate work between different haskell repositories, or merge
everything into a unique repository and call it simply [haskell].



> I note the absence of certain packages like haskell-buildwrapper (which
> EclipseFP tools needs) - and reading the wiki, it seems confusing at this
> time whether the Haskell tinkerer / developer should just be using
> cabal-install to install all required packages (even though I know that
> cabal is not a package management system) or... what?
>

Personally I don't like installing things using cabal-install because in my
opinion the distro package manager should always be in charge.


> What are other Haskell developers here doing currently?
>
> kind regards,
> Dawid Loubser
>
>
>
> On 12/05/2014 08:49, Nicola Squartini wrote:
>
> http-conduit and its dependencies moved from haskell-happstack to
> haskell-core and at that time the package release number reset to one. You
> have to manually uninstall and reinstall those packages.
>
>  Nicola
>
>
> On Sun, May 11, 2014 at 11:49 PM, Michael Katelman wrote:
>
>> I was hoping someone might help me with an issuing I'm having doing a
>> system upgrade. When I run pacman -Syu, I get:
>>
>>  :: Synchronizing package databases...
>> haskell-core is up to date
>> haskell-happstack is up to date
>> core is up to date
>> extra is up to date
>> community is up to date
>> :: Starting full system upgrade...
>> warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than
>> haskell-core (0.8.1.3-2)
>> warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core
>> (0.8.1-2)
>> warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core
>> (0.2.3-1)
>> warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core
>> (0.2.7-1)
>> warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core
>> (0.1.4-1)
>> warning: haskell-connection: local (0.2.1-3) is newer than haskell-core
>> (0.2.1-2)
>> warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core
>> (0.5.2-1)
>> warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than
>> haskell-core (0.0.9-1)
>> warning: haskell-crypto-numbers: local (0.2.3-3) is newer than
>> haskell-core (0.2.3-1)
>> warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than
>> haskell-core (0.2.4-1)
>> warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than
>> haskell-core (0.4.2.2-1)
>> warning: haskell-crypto-random: local (0.0.7-4) is newer than
>> haskell-core (0.0.7-1)
>> warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than
>> haskell-core (0.2.1.1-2)
>> warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core
>> (2.1.2-2)
>> warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core
>> (0.1.0.4-2)
>> warning: haskell-publicsuffixlist: local (0.1-7) is newer than
>> haskell-core (0.1-2)
>> warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core
>> (0.1.3-1)
>> warning: haskell-socks: local (0.5.4-10) is newer than haskell-core
>> (0.5.4-2)
>> warning: haskell-x509: local (1.4.11-5) is newer than haskell-core
>> (1.4.11-2)
>> warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core
>> (1.4.4-2)
>> warning: haskell-x509-validation: local (1.5.0-9) is newer than
>> haskell-core (1.5.0-2)
>> resolving dependencies...
>> looking for inter-conflicts...
>> error: failed to prepare transaction (could not satisfy dependencies)
>> :: haskell-connection: requires haskell-network=2.4.2.2-60
>> :: haskell-connection: requires haskell-tls=1.2.6-5
>> :: haskell-connection: requires haskell-x509=1.4.11-5
>> :: haskell-connection: requires haskell-x509-store=1.4.4-9
>> :: haskell-connection: requires haskell-x509-validation=1.5.0-9
>> :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59
>> :: haskell-cookie: requires haskell-text=1.1.1.1-1
>> :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3
>> :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4
>> :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2
>> :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60
>> :: haskell-http-client-tls: req

Re: [arch-haskell] help upgrading packages

[Dawid Loubser]

I had a similar issue with a large number of packages.
I ended up removing and re-installing my entire Haskell ecosystem, and
now things work again.

I note the absence of certain packages like haskell-buildwrapper (which
EclipseFP tools needs) - and reading the wiki, it seems confusing at
this time whether the Haskell tinkerer / developer should just be using
cabal-install to install all required packages (even though I know that
cabal is not a package management system) or... what?

What are other Haskell developers here doing currently?

kind regards,
Dawid Loubser


On 12/05/2014 08:49, Nicola Squartini wrote:
> http-conduit and its dependencies moved from haskell-happstack to
> haskell-core and at that time the package release number reset to one.
> You have to manually uninstall and reinstall those packages.
>
> Nicola
>
>
> On Sun, May 11, 2014 at 11:49 PM, Michael Katelman  > wrote:
>
> I was hoping someone might help me with an issuing I'm having
> doing a system upgrade. When I run pacman -Syu, I get:
>
> :: Synchronizing package databases...
> haskell-core is up to date
> haskell-happstack is up to date
> core is up to date
> extra is up to date
> community is up to date
> :: Starting full system upgrade...
> warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than
> haskell-core (0.8.1.3-2)
> warning: haskell-asn1-parse: local (0.8.1-5) is newer than
> haskell-core (0.8.1-2)
> warning: haskell-asn1-types: local (0.2.3-3) is newer than
> haskell-core (0.2.3-1)
> warning: haskell-cipher-aes: local (0.2.7-3) is newer than
> haskell-core (0.2.7-1)
> warning: haskell-cipher-rc4: local (0.1.4-4) is newer than
> haskell-core (0.1.4-1)
> warning: haskell-connection: local (0.2.1-3) is newer than
> haskell-core (0.2.1-2)
> warning: haskell-cprng-aes: local (0.5.2-8) is newer than
> haskell-core (0.5.2-1)
> warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer
> than haskell-core (0.0.9-1)
> warning: haskell-crypto-numbers: local (0.2.3-3) is newer than
> haskell-core (0.2.3-1)
> warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than
> haskell-core (0.2.4-1)
> warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer
> than haskell-core (0.4.2.2-1)
> warning: haskell-crypto-random: local (0.0.7-4) is newer than
> haskell-core (0.0.7-1)
> warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than
> haskell-core (0.2.1.1-2)
> warning: haskell-http-conduit: local (2.1.2-4) is newer than
> haskell-core (2.1.2-2)
> warning: haskell-mime-types: local (0.1.0.4-3) is newer than
> haskell-core (0.1.0.4-2)
> warning: haskell-publicsuffixlist: local (0.1-7) is newer than
> haskell-core (0.1-2)
> warning: haskell-securemem: local (0.1.3-3) is newer than
> haskell-core (0.1.3-1)
> warning: haskell-socks: local (0.5.4-10) is newer than
> haskell-core (0.5.4-2)
> warning: haskell-x509: local (1.4.11-5) is newer than haskell-core
> (1.4.11-2)
> warning: haskell-x509-store: local (1.4.4-9) is newer than
> haskell-core (1.4.4-2)
> warning: haskell-x509-validation: local (1.5.0-9) is newer than
> haskell-core (1.5.0-2)
> resolving dependencies...
> looking for inter-conflicts...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: haskell-connection: requires haskell-network=2.4.2.2-60
> :: haskell-connection: requires haskell-tls=1.2.6-5
> :: haskell-connection: requires haskell-x509=1.4.11-5
> :: haskell-connection: requires haskell-x509-store=1.4.4-9
> :: haskell-connection: requires haskell-x509-validation=1.5.0-9
> :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59
> :: haskell-cookie: requires haskell-text=1.1.1.1-1
> :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3
> :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4
> :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2
> :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60
> :: haskell-http-client-tls: requires haskell-tls=1.2.6-5
> :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1
> :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2
> :: haskell-http-conduit: requires haskell-http-types=0.8.4-4
> :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3
> :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5
> :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1
> :: haskell-socks: requires haskell-network=2.4.2.2-60
> :: haskell-x509-system: requires haskell-x509=1.4.11-5
> :: haskell-x509-system: requires haskell-x509-store=1.4.4-9
>
>
> I really have no idea what to do with this or what would have
> caused it. I'm sure it's some important misunderstanding on my
> par

Re: [arch-haskell] help upgrading packages

[Nicola Squartini]

http-conduit and its dependencies moved from haskell-happstack to
haskell-core and at that time the package release number reset to one. You
have to manually uninstall and reinstall those packages.

Nicola


On Sun, May 11, 2014 at 11:49 PM, Michael Katelman wrote:

> I was hoping someone might help me with an issuing I'm having doing a
> system upgrade. When I run pacman -Syu, I get:
>
> :: Synchronizing package databases...
> haskell-core is up to date
> haskell-happstack is up to date
> core is up to date
> extra is up to date
> community is up to date
> :: Starting full system upgrade...
> warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than
> haskell-core (0.8.1.3-2)
> warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core
> (0.8.1-2)
> warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core
> (0.2.3-1)
> warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core
> (0.2.7-1)
> warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core
> (0.1.4-1)
> warning: haskell-connection: local (0.2.1-3) is newer than haskell-core
> (0.2.1-2)
> warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core
> (0.5.2-1)
> warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than
> haskell-core (0.0.9-1)
> warning: haskell-crypto-numbers: local (0.2.3-3) is newer than
> haskell-core (0.2.3-1)
> warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core
> (0.2.4-1)
> warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than
> haskell-core (0.4.2.2-1)
> warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core
> (0.0.7-1)
> warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than
> haskell-core (0.2.1.1-2)
> warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core
> (2.1.2-2)
> warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core
> (0.1.0.4-2)
> warning: haskell-publicsuffixlist: local (0.1-7) is newer than
> haskell-core (0.1-2)
> warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core
> (0.1.3-1)
> warning: haskell-socks: local (0.5.4-10) is newer than haskell-core
> (0.5.4-2)
> warning: haskell-x509: local (1.4.11-5) is newer than haskell-core
> (1.4.11-2)
> warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core
> (1.4.4-2)
> warning: haskell-x509-validation: local (1.5.0-9) is newer than
> haskell-core (1.5.0-2)
> resolving dependencies...
> looking for inter-conflicts...
> error: failed to prepare transaction (could not satisfy dependencies)
> :: haskell-connection: requires haskell-network=2.4.2.2-60
> :: haskell-connection: requires haskell-tls=1.2.6-5
> :: haskell-connection: requires haskell-x509=1.4.11-5
> :: haskell-connection: requires haskell-x509-store=1.4.4-9
> :: haskell-connection: requires haskell-x509-validation=1.5.0-9
> :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59
> :: haskell-cookie: requires haskell-text=1.1.1.1-1
> :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3
> :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4
> :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2
> :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60
> :: haskell-http-client-tls: requires haskell-tls=1.2.6-5
> :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1
> :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2
> :: haskell-http-conduit: requires haskell-http-types=0.8.4-4
> :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3
> :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5
> :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1
> :: haskell-socks: requires haskell-network=2.4.2.2-60
> :: haskell-x509-system: requires haskell-x509=1.4.11-5
> :: haskell-x509-system: requires haskell-x509-store=1.4.4-9
>
>
> I really have no idea what to do with this or what would have caused it.
> I'm sure it's some important misunderstanding on my part. Any help would be
> greatly appreciated.
>
> -Mike
>
> ___
> arch-haskell mailing list
> arch-haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/arch-haskell
>
>
___
arch-haskell mailing list
arch-haskell@haskell.org
http://www.haskell.org/mailman/listinfo/arch-haskell