Support for remapped info from ikdasm/monodis #14090
Labels
Comments
|
I don't think I quite get what you need. The way the remapping works in the runtime is the opposite of what you say. the app might say "I need System.Foo 4.3.0.5" and mono internally just says "you will use my System.Foo and I don't care what version you asked for, I'm gonna pretend you wanted 4.0.0.0". This hack happens in It's probably equal effort to extend |
|
I guess it's an open design question. Right now, an RPM exports something like the following in the metadata: This is based on doing an Then, a consumer declares its requirements based on a recursive So let's cut that down to a minimal example: There's a numbering mismatch, and the dependency is not considered satisfied or satisfiable by RPM. So how can we either provide the numbering in a less precise way, or consume it in a less precise way? My vague idea is when encoding dependencies, rather than using raw |
This approach makes sense to me, given how the runtime works. |
|
IMHO there are inherent design flaws to the entire approach taken by mono-find-provides/requires, but changing them now is basically impossible without breaking support with every existing RPM distro which supports Mono 🤷♂️ So spitballing a more iterative approach to making the mess less bad. |
marek-safar
added
proposal
and removed
area-Runtime: Loader
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Packaging tools for .deb (and especially for RPM) figure out which assemblies exist in a package based on
ikdasm --assembly, and which assemblies are needed based onikdasm --assemblyrefIn the modern world where version numbers are largely ignored, this causes a hell where e.g. a package needs version 4.0.0.0 of something, but we have 4.0.1.3
It would be immensely useful if, in cases where remapping exists, we could either query "what is your version" and get the remapped result, OR "what do you need" and see a remapped list. Or both. Some way to get rid of the mile-long
grep -vlists I've had to add to RPM packages to simply strip dependencies out.The text was updated successfully, but these errors were encountered: