Attempting to make bindingRedirect from Mono.Cecil v0.9.5 to 0.10.0, I've found, since v0.10.0 a PublicKeyToken changed.
v0.9.5, 0.9.6 (& probably some other <0.10.0) have PublicKeyToken - 0738eb9f132ed756
since v0.10.0 and so on (incl. 0.11.3.0 for example) PublicKeyToken - 50cebf1cceb9d05e
It breaks bindingRedirect with cause "PublicKeyToken mismatch".
I wonder, why was it changed (in this case or at general - why do developers change PublicKeyToken of their product)?
Is it intend to underline versions incompatibility?
Related
I was trying to install ripgrep_all using cargo install ripgrep_all. It gave the following error:
% cargo install ripgrep_all
Updating crates.io index
Installing ripgrep_all v0.9.6
error: failed to compile `ripgrep_all v0.9.6`, intermediate artifacts can be found at `/tmp/cargo-install5HlOMt`
Caused by:
failed to select a version for the requirement `cachedir = "^0.1.1"`
candidate versions found which didn't match: 0.3.0, 0.2.0
location searched: crates.io index
required by package `ripgrep_all v0.9.6`
Then I searched a bit and found:
It looks like cachedir yanked version 0.1.1.
And the solution was to:
cargo install --locked ripgrep_all
I was able to install it successfully. However, During the installation it said:
% cargo install --force --locked ripgrep_all
Updating crates.io index
Installing ripgrep_all v0.9.6
warning: package `cachedir v0.1.1` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
warning: package `smallvec v1.4.0` in Cargo.lock is yanked in registry `crates.io`, consider running without --locked
It made me curious. What does Yank mean in rust world?
It means that the package has been marked as "yanked". This is usually done when the authors of have package have a very compelling reason that a certain version of a package should not be used at all, and to very strongly suggest that the package should not be used. You can ignore yanks with --force to force yanked packages to be used, but that is usually a bad idea: packages were usually yanked for a good reason.
In your case: The yanked cachedir 0.1.X version is a completely different package with a different author than the newer versions. The older versions are unmaintained and cannot be updated (since cachedir now has a different owner who publishes a different package), so the new owner of cachedir yanked the older versions. smallvec 1.4.0 has a bug where it causes Undefined Behaviour when used with zero-sized types, and that UB is bad enough that it is exceedingly unlikely that you actually want to use that version. The fix to this is to update to a later version of smallvec that doesn't have that bug.
All I want is to parse a simple string using regex.
First question: Should I be using Text.Regex or something else? Stackage lists at least 11 regex packages. I don't care if it's PCRE or Posix. At this point I'll accept anything.
Second Question: How do I include Text.Regex in my project? This is my experience so far:
package.yaml has
dependencies:
- base >= 4.7 && < 5
- regex
stacky.yaml attempt 1
extra-deps:
- regex-1.0.1.3
Response to stack build
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for regex-1.0.1.3:
base-compat-0.10.5 from stack configuration does not match >=0.6 && <0.10 (latest matching version is 0.9.3)
template-haskell-2.13.0.0 from stack configuration does not match >=2.7 && <2.12 (latest matching version is 2.11.1.0)
needed due to CCompiler-0.1.0.0 -> regex-1.0.1.3
Some different approaches to resolving this:
* Set 'allow-newer: true' to ignore all version constraints and build anyway.
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many complicated constraint
errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /Users/adamfrank/Dev/Haskell/CCompiler/stack.yaml:
- base-compat-0.9.3
- template-haskell-2.11.1.0
Plan construction failed.
stack.yaml attempt 2
extra-deps:
- regex-1.0.1.3
- base-compat-0.9.3
- template-haskell-2.11.1.0
Response to stack build:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for regex-1.0.1.3:
template-haskell-2.13.0.0 from stack configuration does not match >=2.7 && <2.12 (latest matching version is 2.11.1.0)
needed due to CCompiler-0.1.0.0 -> regex-1.0.1.3
Some different approaches to resolving this:
* Set 'allow-newer: true' to ignore all version constraints and build anyway.
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many complicated constraint
errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /Users/adamfrank/Dev/Haskell/CCompiler/stack.yaml:
- template-haskell-2.11.1.0
Plan construction failed.
???
It says I need to add a line I already added.
Do I need a different version of regex? If so, which one, and how do I figure that out?
There are a few recommendations in the comments as to what to use: regex-base, but it is also good to understand why it is not compiling.
Stackage provides a list of compatible packages in each LTS. You can alter some of the version numbers as long as they respect the version constraints of other dependencies. Not all of these dependency restrictions are well defined in the packages coming from Hackage, which is one of the reasons for using Stackage.
Generally each stackage major LTS release is associated with a particular version of GHC which also has a particular version of base. When you pick a major version of LTS, you are also picking a version of GHC and base. If you want to change GHC and/or base versions, it is easier to change the LTS version. The first thing after the LTS version on the Stackage LTS page is the GHC version number.
In your case regex requires a version of template-haskell and base-compat that violate the constraints of other dependencies.
I'm trying to upgrade the dependencies of the pipes-files package, so that it can be included in the latest stack LTS. The pipes-files package does not contain a stack.yaml file, and the pipes-files.cabal file contains quite some upper and lower bounds on its dependencies, e.g.:
base >=4.7 && <4.10
, transformers >=0.3 && <0.6
, transformers-base >=0.3 && <0.6
-- and quite some more ...
Is there a tool that I can run to get the latest versions of each of these dependencies? The closest thing I could find was packdeps but it will require me to search for the dependencies one by one.
Preliminary notes:
hierarchy, a dependency of pipes-files, has the same issue you are trying to work around -- it is not in Stackage and has version bounds outdated with respect to the latest LTS. That means you'll first have to get it to build successfully, and then add your tweaked version of it to the extra-deps in the stack.yaml of pipes-files.
cabal gen-bounds, which "suggest[s] dependency version bounds that conform to Package Versioning Policy", is, in principle, the right tool for the job. However, getting cabal-install to behave according to the restrictions of a Stack-centric environment is not always straightforward. While this seems enough to run cabal gen-bounds from a bash shell in the absence of a Stack-independent GHC installation...
PATH=$PATH:$(stack path --compiler-bin) cabal gen-bounds
... I couldn't figure out how to get it to follow the version restrictions of the Stack(age) snapshot -- in particular, the --package-db option, which can be helpful with commands such as cabal configure, doesn't seem to be accepted by gen-bounds.
As I don't know how to make cabal gen-bounds and Stack cooperate, I will suggest a somewhat more convoluted method, but one that doesn't require using cabal-install directly. It uses Jenga, a tool that can retrieve the version information left implicit by your choice of Stackage snapshot. Jenga is not on Stackage; to install it with Stack, grab the sources from GitHub (or with stack unpack jenga) and then run stack init --solver followed by stack install.
Remove all version bounds from the hierarchy.cabal file (or whatever the relevant .cabal file is).
stack init --solver, to create a stack.yaml file with any extra-deps that might be necessary. (You can use --resolver to explicitly choose the snapshot to be used.)
stack build, as a sanity check that the package is buildable.
In the generated stack.yaml, check whether the extra-deps field is commented out; if so, uncomment it. This is necessary for step #6 to work.
jenga -i hierarchy.cabal, which will print the exact dependency versions Stack would use to build the package.
Paste the versions Jenga gave you into the build-depends of the .cabal file, adjusting then if desired (at a minimum, you'll probably want to relax the minor version bounds for PVP compliance -- e.g. changing base == 4.9.1.0 to base == 4.9.*).
I've tried stack clean, and also removing .stack-work.
But still, every time I run build it unregisters 5 (the same) packages.
stack build --dry-run tells me the list, but not any reason why.
I've also recently upgraded from 1.4.1
Also, if it is not quite simple how to figure this out, I'd like to get back to using 1.4.1. Any simple way to downgrade haskell-stack to that version?
Edit 1
Downgrading to 1.4.0 didn't help. About 70 packages got unregistered and rebuilt, and after that I got into the same 5-unregister-loop.
So I thought, where else could have my local state be corrupted since ~yesterday? ~/.stack! So I've (re)moved my ~/.stack folder, and also .stack-work folder, thinking that if anything could have gone wrong it's in these two places, and now I am in an even worse of a rut. Now the constant unregister cycle includes 23 packages (some of them quite heavy) instead of just 5.
Would unregister locally:
cairo-0.13.3.1 (missing dependencies: gtk2hs-buildtools)
dump-0.3.0 (missing dependencies: haskell-src-meta, interpolatedstring-perl6)
entropy-0.3.7
ghcjs-dom-0.2.4.0 (missing dependencies: glib, gtk3, webkitgtk3)
gio-0.13.3.1 (missing dependencies: glib, gtk2hs-buildtools)
glib-0.13.4.1 (missing dependencies: gtk2hs-buildtools)
gtk2hs-buildtools-0.13.2.2 (missing dependencies: happy)
gtk3-0.14.6 (missing dependencies: cairo, gio, glib, gtk2hs-buildtools, pango)
haskell-src-exts-1.17.1 (missing dependencies: happy)
haskell-src-meta-0.6.0.14 (missing dependencies: haskell-src-exts)
here-1.2.9 (missing dependencies: haskell-src-meta)
hs-di-0.4.0 (missing dependencies: haskell-src-meta, interpolate, interpolatedstring-perl6)
interpolate-0.1.0 (missing dependencies: haskell-src-meta)
interpolatedstring-perl6-1.0.0 (missing dependencies: haskell-src-meta)
pango-0.13.3.1 (missing dependencies: cairo, glib, gtk2hs-buildtools)
reflex-0.5.0 (missing dependencies: haskell-src-exts, haskell-src-meta)
reflex-dom-0.4 (missing dependencies: ghcjs-dom, glib, gtk3, reflex, webkitgtk3, webkitgtk3-javascriptcore)
threepenny-gui-0.7.1.0
uuid-1.3.13
webkitgtk3-0.14.2.1 (missing dependencies: cairo, glib, gtk2hs-buildtools, gtk3, pango)
webkitgtk3-javascriptcore-0.13.2.0 (missing dependencies: glib, gtk2hs-buildtools, gtk3, webkitgtk3)
websockets-0.9.8.2
websockets-snap-0.10.0.0
#user2407038, what kind of information might help to start diagnosing this? Is the above helpful to begin with? Under what circumstances can ever such an unregister-loop arise?
I have one more idea that I could try: this particular project depends on a few local packages, and afaik their .stack-work folder may play a role in this. So maybe I could (re)move those as well.
Any more ideas should the above one fail?
Long story short: changing resolver: lts-7.19 to resolver: lts-7.24 in stack.yaml seems to have fixed the error for me.
I have some guesses and hunches what may have gone wrong in the background, but I am not entirely sure.
I got a clue from the --dry-run flag that some of the missing packages it reports are build-time haskell package dependencies, like alex, happy, etc...
So maybe the older lts didn't install those correctly? If someone is more knowledgeable on the subject, I'd love to hear more.
And I'm also sad that this incident has destroyed some of my trust in stack's promise of reproducible builds, as a (AFAIK purported-to-be-safe) stack upgrade (and even with subsequent downgrade) suddenly left one of my projects un-buildable for days.
And at any rate, I'd love if
stack would warn and ask me before it makes destructive changes on my system, especially if it results in hours of recompilation. (Which actually meant days of head-scratching in my case since any idea I tried I had to wait quite a bit of time in-between.)
It could employ a similar build store as nix, whereas even if I change some configuration, I can switch back to the previous working configuration readily.
As a partial solution, I found that I can
stack upgrade --binary-version 1.4.0
Which readily performs the downgrade:
Current Stack version: 1.5.1, available download version: 1.4.0
Forcing binary upgrade
Querying for archive location for platform: linux-x86_64-static
Downloading from: https://github.com/commercialhaskell/stack/releases/download/v1.4.0/stack
-1.4.0-linux-x86_64-static.tar.gz
Download complete, testing executable
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64
hpack-0.17.0
New stack executable available at /home/user/.local/bin/stack
It could have been the case the you were hitting this bug: Better calculation of SourceMap, but again not enough information to tell for sure. Considering that this issue will get fixed soon, it shouldn't be a problem anymore, but if anyone is looking for a work around custom snapshots seem to work pretty well.
The gist of custom snapshots is by moving all immutable packages from extra-deps into a custom snapshot will prevent stack from recalculating dependencies for these packages.
My RPM package has this in its dependencies list:
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
What do the strings in parenthesis mean? And if it is an ABI version, how can I change, replace or delete the dependency?
Depending on your installed gcc/libstdc++ you may need a more recent libstdc++
See also http://glandium.org/blog/?p=1901 and http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
For basic info you can also read http://en.wikipedia.org/wiki/Application_binary_interface
You can'd change, replace, or delete the dependency. If it's required, it's required. You can force it to install but it'll be broken (won't launch).
What you could do is to recompile the code from source.