Cblrepo and dependencies
I'm trying to build cblrepo on this machine, but something has gone quite wrong. It says it need Unixutils 1.52.* for example. When I install unixutils, it still says it is missing. During unixutils installation I get these errors: Unixutils-1.53: dependency "process-extras-0.3.3.4-acf7cfde64a7eeb8de77ed902f28b42e" doesn't exist (use --force to override) Unixutils-1.53: dependency "regex-tdfa-1.2.0-d609432fe2944ef942a3146ddaef05ca" doesn't exist (use --force to override) Unixutils-1.53: dependency "zlib-0.5.4.2-7f8fa1baff7481f1dca70c1ad6ffca0e" doesn't exist (use --force to override) I can install them manually, but should I have to? -- SP
On Thu, Apr 23, 2015 at 04:08:04PM +0100, SP wrote:
I'm trying to build cblrepo on this machine, but something has gone quite wrong. It says it need Unixutils 1.52.* for example.
When I install unixutils, it still says it is missing. During unixutils installation I get these errors:
Unixutils-1.53: dependency "process-extras-0.3.3.4-acf7cfde64a7eeb8de77ed902f28b42e" doesn't exist (use --force to override) Unixutils-1.53: dependency "regex-tdfa-1.2.0-d609432fe2944ef942a3146ddaef05ca" doesn't exist (use --force to override) Unixutils-1.53: dependency "zlib-0.5.4.2-7f8fa1baff7481f1dca70c1ad6ffca0e" doesn't exist (use --force to override)
haskell-unixutils installs fine here. What's the output of: pacman -Q haskell-regex-tdfa
On 23 April 2015 at 17:08, SP
I'm trying to build cblrepo on this machine, but something has gone quite wrong. It says it need Unixutils 1.52.* for example.
When I install unixutils, it still says it is missing. During unixutils installation I get these errors:
Unixutils-1.53: dependency "process-extras-0.3.3.4-acf7cfde64a7eeb8de77ed902f28b42e" doesn't exist (use --force to override) Unixutils-1.53: dependency "regex-tdfa-1.2.0-d609432fe2944ef942a3146ddaef05ca" doesn't exist (use --force to override) Unixutils-1.53: dependency "zlib-0.5.4.2-7f8fa1baff7481f1dca70c1ad6ffca0e" doesn't exist (use --force to override)
I can install them manually, but should I have to?
It depends on what you mean by 'installing them manually'. I try to keep the dependencies of `cblrepo` on the master branch at github in sync with the packages available from the ArchHaskell repo, so it should always be possible to use `pacman` to install them all. If you find that the depencencies of `cblrepo` can't be satisfied by ArchHaskell then it's a bug and I'd appreciate it if you raise a ticket on github :) If `haskell-unixutils` as found in the repo isn't installable, then that's a bug too. To keep the storage usage down I tend to clean out old packages rather aggressively, so make sure to update your repo data (`pacman -Sy`) often. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 07:17, Magnus Therning wrote:
It depends on what you mean by 'installing them manually'.
Explicitly telling Pacman to install them.
If you find that the depencencies of `cblrepo` can't be satisfied by ArchHaskell then it's a bug and I'd appreciate it if you raise a ticket on github :)
I will if I determine whether it is a bug. I have a hunch I have done something which has unregistered/misregistered which Haskell packages are installed.
If `haskell-unixutils` as found in the repo isn't installable, then that's a bug too. To keep the storage usage down I tend to clean out old packages rather aggressively, so make sure to update your repo data (`pacman -Sy`) often.
What are the commands for reinstalling all of ArchHaskell based packages? -- SP
On 24 April 2015 at 10:18, SP
On 24/04/15 07:17, Magnus Therning wrote:
It depends on what you mean by 'installing them manually'.
Explicitly telling Pacman to install them.
Yes, to build `cblrepo` from source you do need to manually ensure its requirements are present.
If you find that the depencencies of `cblrepo` can't be satisfied by ArchHaskell then it's a bug and I'd appreciate it if you raise a ticket on github :)
I will if I determine whether it is a bug. I have a hunch I have done something which has unregistered/misregistered which Haskell packages are installed.
If `haskell-unixutils` as found in the repo isn't installable, then that's a bug too. To keep the storage usage down I tend to clean out old packages rather aggressively, so make sure to update your repo data (`pacman -Sy`) often.
What are the commands for reinstalling all of ArchHaskell based packages?
Personally I tend to first delete all Haskell dev packages: `pacman -Rncs ghc`. Then I manually install whatever packages I need at the moment. Of course it ought to be possible to automate it through some scripting, but I have had to do this so rarely that I've not deemed it necessary to put together such a script (or even think about how it could be done). Also, double check that `[haskell-core]` is listed berfore `[Extra]` in your pacman config (http://is.gd/O3HkZN). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 09:42, Magnus Therning wrote:
Yes, to build `cblrepo` from source you do need to manually ensure its requirements are present.
No I meant packages I have told pacman to install to satisfy cblrepo building, don't have their respective dependencies.
Personally I tend to first delete all Haskell dev packages: `pacman -Rncs ghc`. Then I manually install whatever packages I need at the moment.
This is good enough. Going through the process now.
Also, double check that `[haskell-core]` is listed berfore `[Extra]` in your pacman config (http://is.gd/O3HkZN).
Yeah that was ok. -- SP
On 24/04/15 09:42, Magnus Therning wrote:
Personally I tend to first delete all Haskell dev packages: `pacman -Rncs ghc`.
Done thins. And also run `pacman -Sc` (clean cache) for good measure, but I got this: Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... error: could not open file /var/cache/pacman/pkg/haskell-connection-0.2.3-5-x86_64.pkg.tar.xz: Unrecognized archive format error: missing package metadata in /var/cache/pacman/pkg/haskell-http-client-tls-0.2.2-12-x86_64.pkg.tar.xz.part error: could not open file /var/cache/pacman/pkg/haskell-cookie-0.4.1.3-3-x86_64.pkg.tar.xz: Unrecognized archive format error: could not open file /var/cache/pacman/pkg/haskell-yaml-0.8.9.1-3-x86_64.pkg.tar.xz: Unrecognized archive format error: could not open file /var/cache/pacman/pkg/haskell-crypto-numbers-0.2.3-6-x86_64.pkg.tar.xz: Unrecognized archive format [...] Goes on, but errors regarding haskell packages are that it could not open file. maybe something else had gone wrong.. Still researching. -- SP
On 24 April 2015 at 12:21, SP
On 24/04/15 09:42, Magnus Therning wrote:
Personally I tend to first delete all Haskell dev packages: `pacman -Rncs ghc`.
Done thins. And also run `pacman -Sc` (clean cache) for good measure, but I got this:
Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... error: could not open file /var/cache/pacman/pkg/haskell-connection-0.2.3-5-x86_64.pkg.tar.xz: Unrecognized archive format error: missing package metadata in /var/cache/pacman/pkg/haskell-http-client-tls-0.2.2-12-x86_64.pkg.tar.xz.part error: could not open file /var/cache/pacman/pkg/haskell-cookie-0.4.1.3-3-x86_64.pkg.tar.xz: Unrecognized archive format error: could not open file /var/cache/pacman/pkg/haskell-yaml-0.8.9.1-3-x86_64.pkg.tar.xz: Unrecognized archive format error: could not open file /var/cache/pacman/pkg/haskell-crypto-numbers-0.2.3-6-x86_64.pkg.tar.xz: Unrecognized archive format [...]
Goes on, but errors regarding haskell packages are that it could not open file. maybe something else had gone wrong.. Still researching.
My spontaneous reaction is that it looks filesystem related. I'd personally start with running `fsck` on the file system to see if that clears up the issues you see above. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 11:45, Magnus Therning wrote:
My spontaneous reaction is that it looks filesystem related. I'd personally start with running `fsck` on the file system to see if that clears up the issues you see above.
Listing the cache directory showed those Haskell packages to be of tiny size. I presumed it was an issue when downloading them (I have those on this machine cause I am behind proxy). So I scrapped the whole cache with `pacman -Scc` and I'm on to the next stage now. I was installing cblrepo's dependencies one by one and they were disappearing from the missing list, until I accidentally got `ghc` package to reinstall again. I thought it would be fine but it warned me with: ==> All cabalized packages need to be reinstalled now. ==> See /usr/share/haskell/ and ghc-pkg list --user for a tentative list of affected packages. And now clbrepo `./Setup.hs configure` complains all dependencies missing again like before. Reinstalling any of the packages as suggested doesn't work. For example I get this when reinstalling _haskell-unixutils_: ghc-pkg: cannot find package Unixutils-1.53 error: command failed to execute correctly (1/1) reinstalling haskel-unixutils [###################] 100% Reading package info from stdin ... done. Unixutils-1.53: dependency "exceptions-0.8.0.2-067eead0ac0060ab628c11ede1c51b50" doesn't exist (use --force to override) Unixutils-1.53: dependency "mtl-2.2.1-9986828fc95bc8459870303efaabd81e" doesn't exist (use --force to override) Unixutils-1.53: dependency "process-extras-0.3.3.4-acf7cfde64a7eeb8de77ed902f28b42e" doesn't exist (use --force to override) Unixutils-1.53: dependency "pureMD5-2.1.2.1-30e721cd6127d447646b1e2fec789dbd" doesn't exist (use --force to override) Unixutils-1.53: dependency "regex-tdfa-1.2.0-d609432fe2944ef942a3146ddaef05ca" doesn't exist (use --force to override) Unixutils-1.53: dependency "zlib-0.5.4.2-7f8fa1baff7481f1dca70c1ad6ffca0e" doesn't exist (use --force to override) So I guess this is how to reproduce the issue. Not sure if it a bug or something I should be doing after reinstalling the _ghc_ package. -- SP
On 24 April 2015 at 13:09, SP
On 24/04/15 11:45, Magnus Therning wrote:
My spontaneous reaction is that it looks filesystem related. I'd personally start with running `fsck` on the file system to see if that clears up the issues you see above.
Listing the cache directory showed those Haskell packages to be of tiny size. I presumed it was an issue when downloading them (I have those on this machine cause I am behind proxy). So I scrapped the whole cache with `pacman -Scc` and I'm on to the next stage now.
I was installing cblrepo's dependencies one by one and they were disappearing from the missing list, until I accidentally got `ghc` package to reinstall again. I thought it would be fine but it warned me with:
==> All cabalized packages need to be reinstalled now. ==> See /usr/share/haskell/ and ghc-pkg list --user for a tentative list of affected packages.
And now clbrepo `./Setup.hs configure` complains all dependencies missing again like before. Reinstalling any of the packages as suggested doesn't work. For example I get this when reinstalling _haskell-unixutils_:
ghc-pkg: cannot find package Unixutils-1.53 error: command failed to execute correctly (1/1) reinstalling haskel-unixutils [###################] 100% Reading package info from stdin ... done. Unixutils-1.53: dependency "exceptions-0.8.0.2-067eead0ac0060ab628c11ede1c51b50" doesn't exist (use --force to override) Unixutils-1.53: dependency "mtl-2.2.1-9986828fc95bc8459870303efaabd81e" doesn't exist (use --force to override) Unixutils-1.53: dependency "process-extras-0.3.3.4-acf7cfde64a7eeb8de77ed902f28b42e" doesn't exist (use --force to override) Unixutils-1.53: dependency "pureMD5-2.1.2.1-30e721cd6127d447646b1e2fec789dbd" doesn't exist (use --force to override) Unixutils-1.53: dependency "regex-tdfa-1.2.0-d609432fe2944ef942a3146ddaef05ca" doesn't exist (use --force to override) Unixutils-1.53: dependency "zlib-0.5.4.2-7f8fa1baff7481f1dca70c1ad6ffca0e" doesn't exist (use --force to override)
So I guess this is how to reproduce the issue. Not sure if it a bug or something I should be doing after reinstalling the _ghc_ package.
Sorry, but I don't understand what steps you are performing. How do you get ghc to "accidentally" install a second time? After running `pacman -Rncs ghc` *everything* related to haskell development ought to disappear. I'd also suggest you clean out any locally installed packages (e.g. via `cabal install`). After that, the very first haskell package you install, e.g. `haskell-unixutils`, will pull in ghc as well. In other words, there is no need to explicitly install ghc at all. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 12:16, Magnus Therning wrote:
Sorry, but I don't understand what steps you are performing. How do you get ghc to "accidentally" install a second time?
Because `Setup.hd configure` complained `base` dependency was missing, my reflexive reaction was to install `haskell-base`. That reinstalled ghc.
After running `pacman -Rncs ghc` *everything* related to haskell development ought to disappear.
And that is what happened. I am purging everything again now and will try to avoid causing ghc to reinstall. But is it possible to fix this behaviour? Maybe there is a pacman flag to disallow a package from reinstalling if there are such installation order dependencies.
I'd also suggest you clean out any locally installed packages (e.g. via `cabal install`).
Will do. -- SP
On 24 April 2015 at 13:37, SP
On 24/04/15 12:16, Magnus Therning wrote:
Sorry, but I don't understand what steps you are performing. How do you get ghc to "accidentally" install a second time?
Because `Setup.hd configure` complained `base` dependency was missing, my reflexive reaction was to install `haskell-base`. That reinstalled ghc.
After running `pacman -Rncs ghc` *everything* related to haskell development ought to disappear.
And that is what happened. I am purging everything again now and will try to avoid causing ghc to reinstall. But is it possible to fix this behaviour? Maybe there is a pacman flag to disallow a package from reinstalling if there are such installation order dependencies.
I'd also suggest you clean out any locally installed packages (e.g. via `cabal install`).
Will do.
I've just verified these steps work for me: ~~~ % sudo pacman -Rncs ghc % sudo pacman -S haskell-{unixutils,aeson,ansi-wl-pprint,mtl,optparse-applicative,safe,stringsearch,tar,utf8-string,zlib} % ./Setup.hs configure % ./Setup.hs build ~~~ /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 12:41, Magnus Therning wrote:
~~~ % sudo pacman -Rncs ghc % sudo pacman -S haskell-{unixutils,aeson,ansi-wl-pprint,mtl,optparse-applicative,safe,stringsearch,tar,utf8-string,zlib} % ./Setup.hs configure % ./Setup.hs build ~~~
Good, on my way to doing that too, that isn't the problem. Clearly I somehow managed to mess the local repository here. As I said it happens a lot because of some networking/security related issues with this machine. But the question is, what happens is someone (unnecessarily/accidentally) manages to reinstall ghc? Is the whole set of haskell-* packages then unusable? Cause that seemed to be the effect it had on me. This is the issue I was trying to discuss here. Can you see what happens if you reinstall ghc? -- SP
On 24 April 2015 at 13:52, SP
On 24/04/15 12:41, Magnus Therning wrote:
~~~ % sudo pacman -Rncs ghc % sudo pacman -S haskell-{unixutils,aeson,ansi-wl-pprint,mtl,optparse-applicative,safe,stringsearch,tar,utf8-string,zlib} % ./Setup.hs configure % ./Setup.hs build ~~~
Good, on my way to doing that too, that isn't the problem. Clearly I somehow managed to mess the local repository here. As I said it happens a lot because of some networking/security related issues with this machine.
But the question is, what happens is someone (unnecessarily/accidentally) manages to reinstall ghc? Is the whole set of haskell-* packages then unusable? Cause that seemed to be the effect it had on me.
This is the issue I was trying to discuss here. Can you see what happens if you reinstall ghc?
Ah :) If I re-install ghc all information about installed packages is lost, on the ghc-level, and when I try to re-install e.g. `haskell-unixutils` I get the same kind of error you were seeing. The root cause is that we use a mix of package management, `pacman` keeps track of distro-level packages, and `ghc-pkg` keeps track of the ghc level. When re-installing ghc these two databases aren't in sync anymore and using `pacman` to install results in errors on the `ghc-pkg` level. Basically, `pacman` won't re-install all dependencies, since they are already installed, but when registering with `ghc-pkg` it has no records of those dependencies. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 24/04/15 13:04, Magnus Therning wrote:
If I re-install ghc all information about installed packages is lost, on the ghc-level [..] When re-installing ghc these two databases aren't in sync anymore and using `pacman` to install results in errors on the `ghc-pkg` level. Basically, `pacman` won't re-install all dependencies, since they are already installed, but when registering with `ghc-pkg` it has no records of those dependencies.
Can we protect the system from such mistakes? I guess the ideal solution would be to rsync the databases somehow after ghc is reinstalled. -- SP
On Fri, Apr 24, 2015 at 02:51:08PM +0100, SP wrote:
On 24/04/15 13:04, Magnus Therning wrote:
If I re-install ghc all information about installed packages is lost, on the ghc-level [..] When re-installing ghc these two databases aren't in sync anymore and using `pacman` to install results in errors on the `ghc-pkg` level. Basically, `pacman` won't re-install all dependencies, since they are already installed, but when registering with `ghc-pkg` it has no records of those dependencies.
Can we protect the system from such mistakes? I guess the ideal solution would be to rsync the databases somehow after ghc is reinstalled.
The only solution I can see is to do something clever in the ghc.install (`pre_upgrade` and `post_upgrade`). I'm not sure exactly what information is available though. One would probably need enough information to distinguish a re-install from an upgrade. I should add that you are the very first one ever to report this problem. Also, I'm still not clear on *why* `pacman` all of a sudden decides to re-install ghc on your system. If you figure out why, then that might very well be a more natural place to fix the issue than inside the ghc package. (I'm guessing random re-installs can happen for other packages on your system, though not with such disastrous effects.) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Unix is the answer, but only if you phrase the question very carefully. -- Unknown
On 24/04/15 16:11, Magnus Therning wrote:
The only solution I can see is to do something clever in the ghc.install (`pre_upgrade` and `post_upgrade`). I'm not sure exactly what information is available though. One would probably need enough information to distinguish a re-install from an upgrade.
It think that for the sake of integrity this should happen. Not saying it is a critical bug which needs any immediate attention. Maybe something we can open a low priority issue for and fix when the opportunity arises.
Also, I'm still not clear on *why* `pacman` all of a sudden decides to re-install ghc on your system.
I think given that it is a possibility, the package should cater for it. One may have wanted to install Ghc again for various reasons.
If you figure out why, then that might very well be a more natural place to fix the issue than inside the ghc package.
I mentioned it in a previous email. I told packman to install `haskell-base` because the Setup complained `base` was missing. -- SP
On 27 April 2015 at 10:24, SP
On 24/04/15 16:11, Magnus Therning wrote:
The only solution I can see is to do something clever in the ghc.install (`pre_upgrade` and `post_upgrade`). I'm not sure exactly what information is available though. One would probably need enough information to distinguish a re-install from an upgrade.
It think that for the sake of integrity this should happen. Not saying it is a critical bug which needs any immediate attention. Maybe something we can open a low priority issue for and fix when the opportunity arises.
Also, I'm still not clear on *why* `pacman` all of a sudden decides to re-install ghc on your system.
I think given that it is a possibility, the package should cater for it. One may have wanted to install Ghc again for various reasons.
What reasons would that be?
If you figure out why, then that might very well be a more natural place to fix the issue than inside the ghc package.
I mentioned it in a previous email. I told packman to install `haskell-base` because the Setup complained `base` was missing.
Yes, I understand that, but *why* did it go missing. Somewhere during the installation of haskell packages your ghc package database was changed (corrupted?) in such a way that ghc lost records of `base`. I'd really like to know why. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 27/04/15 12:02, Magnus Therning wrote:
What reasons would that be?
Maybe some file damage by accident. Also accidentally or under misconception that this would fix something. It is an operation supported by pacman, so the package should, _ideally_, cater for it.
Yes, I understand that, but *why* did it go missing. Somewhere during the installation of haskell packages your ghc package database was changed (corrupted?) in such a way that ghc lost records of `base`. I'd really like to know why.
That I don't know and it would be impossible to work back, as I have reinstalled it. Sorry.. Maybe it will happen again. -- SP
On 29 April 2015 at 12:01, SP
On 27/04/15 12:02, Magnus Therning wrote:
What reasons would that be?
Maybe some file damage by accident. Also accidentally or under misconception that this would fix something. It is an operation supported by pacman, so the package should, _ideally_, cater for it.
As you say, `pacman` supports re-installation, but I'm not sure it's a requirement that all packages are idempotent in the sense that they re-instate changes that *other* packages have caused to the system state. A patch is always welcome, of course. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
participants (3)
-
Magnus Therning -
Skottish -
SP