When I install a Nuget package X that depend on package D version >= 0.0.2.0.
And I already have the D package version 0.0.10.0 installed. Is it going to remove the existing D version and install the 0.0.2.0 or keep the version 0.0.10 since its newer?
Is version 0.0.10.0 is >= 0.0.2.0 in nuget or not?
As stated in this NuGet doc, NuGet uses the rules of the Semantic Versioning spec, which states that:
Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
Related
I have freetype2 installed on my system but I am also trying to install it from source, as well.
My installed version is here: /usr/lib64/pkgconfig/freetype2.pc. That file is listed as version 20.0.14.
To compile another tool, namely fontconfig, I need freetype2 >= 21.0.15.
So I downloaded freetype2 from its source git repo.
The trouble I'm having is that repository doesn't list any version even close to 21.0.15+. All of the tags in that repository are listed as VER-2-6-2, VER-2-9, VER-2-9-1, etc. And the generated freetype.pc file which is created after compilation are also listed as 2.6.2, 2.9, 2.9.1, etc. The version number is not 21.0.15 or even 20.0.14, which my CentOS 7.6 already has.
What determines the listed version in the freetype.pc file? Where can I find the version of freetype that will create a .pc file of >= 21.0.15+? Any clarification would be greatly appreciated.
Apparently the reason is because I was building freetype using CMake. And in the CMakeLists.txt, it's defining a version based on the version of freetype.
# . `CMakeLists.txt' is provided as-is since it is normally not used by the
# developer team.
So it's unsupported. That's why the version number doesn't match.
In reality, the version number actually comes from libtool. See this table. e.g. I was building 2.10.0 freetype, so the freetype.pc should have been written with a version of 23.0.17
And if you build using configure, instead of cmake, you can find that exact same version 23.0.17 listed as "23:0:17" in the builds/unix/configure.raw file.
I've just discovered (for myself) that NPM doesn't work like other package management systems I've used in the past. My basic understanding of things is that each of my dependencies will also have its own node_modules folder with it's own dependencies (and, with more recent versions of npm, that this second node_modules folder will only be created when there's a version conflict)
This seems pretty neat, but I'm left wondering how npm handles -- sub-sub? -- dependency conflicts. I apologies for not having a better grip on the language -- but here's what I mean.
I want to install version 3.0 of #foo/bar into my project.
A second-package -- let's call it #second/package -- I have wants to install version 2.0 of #foo/bar.
I now understand how this is possible with NPM. The #second/package will have it's own node_modules folder with version 2.0 of #foo/bar
./node_modules/#foo/bar # version 3.0
./node_modules/#second/package/node_modules/#foo/bar # version 2.0
However --
I also want to install version 8.0 of #zip/zap.
But #second/package wants install version 7.0 of #zip/zap.
And version 2.0 of #foo/bar wants to install version 6.0 of #zip/zap.
./node_modules/#foo/bar # version 3.0
./node_modules/#zip/zap # version 8.0
./node_modules/#second/package/node_modules/#foo/bar # version 2.0
./node_modules/#second/package/node_modules/#zip/zip # version 7.0
# where does version 6.0 of #zip/zap go?
Where does version 6.0 of #zip/zap end up? Does npm create a third level node_module folder, or does it give up and say it can't resolve this dependency tree? Or some third thing? Or is my understanding of npm still flawed?
Before I go and figure out how to setup my own npm repository with fake packages to test this out, I thought it'd be better to ask.
NPM, to my surprise, just does the right thing and continues to nest sub-dependency dependencies. i.e., the answer the question
where does version 6.0 of #zip/zap go?
is
./node_modules/#second/package/node_modules/#foo/bar/node_modules/#zip/zap
Webjobs version 3 has been out since around September so I want to upgrade from 2.3.0 to the latest version, currently 3.0.4.
The Microsoft.Azure.Webjobs.servicebus package is, however, blocking me from doing so. I tried looking at webjobs sdk samples but they had the exact same issue with the servicebus package blocking the upgrade.
Questions
What is the correct way to upgrade the webjobs nuget package?
Am I mistaken that version 3 is ready for production yet?
At the time I'm writing this, the newest release version of Microsoft.Azure.WebJobs.ServiceBus is 2.3.0. Looking at the package on nuget.org and expanding the dependencies, I see this:
Microsoft.Azure.ServiceBus.EventProcessorHost (>= 2.2.10)
Microsoft.Azure.WebJobs (= 2.3.0)
Microsoft.Extensions.Logging.Abstractions (>= 1.1.1) Newtonsoft.Json
(>= 9.0.1) WindowsAzure.ServiceBus (>= 3.4.5)
Notice how the version number for the Microsoft.Azure.WebJobs dependency uses = and not >= like the other dependencies. Therefore, NuGet is being instructed to not allow different versions of the package.
There are some 3.0.0 beta packages you could try, which interestingly use >= for the WebJobs dependency, so you can use the latest "release" version of WebJobs package while using the ServiceBus beta package. Or, if you can migrate from packages.config to PackageReference, NuGet may allow you to use "incompatible" versions of packages with a warning, but if the package author is telling you that their package only works with a specific version of a dependency, there's an increased risk that you'll get runtime failures if you use a different version.
Looking at the package Microsoft.Azure.WebJobs.ServiceBus on nuget.org, it doesn't seem to be maintained:
The last release was on 29 Nov 2018 - over a year ago.
The last beta was on 30 Aug 2018, also over a year ago. Several betas, with no release following them.
This looks abandoned. Has the package been renamed? Or the functionality folded into a different package? Why is there no upgrade path guidance here?
The disparity between the dependencies of this package and others in use are starting to cause issues for us.
I have an RPM that requires TBB >= 4, however on aws linux I only have tbb 2.x. I have compiled tbb 4.3 from source and places the files in /usr/include/tbb & /usr/include/serial/tbb.
If I now manually try to install with rpm -ivh, the install fails with a message
error: Failed dependencies:
tbb >= 4 is needed by xxx.rpm
So how can I tell the install that the new version is available in /usr/include/tbb?
thx Art
If you are installing an RPM that requires TTB >= 4, then presumably there exists in the same source a necessary version of TBB. Otherwise, it sounds like you are trying to mix and match RPMs from different sources in ways that are almost guaranteed to cause problems.
You need to either (a) install a package that contains the necessary dependency information to satisfy TBB version requirement, or (b) you need to install everything from source instead of a single dependency.
While you could build a package yourself satisfying (a), the fact that you have an rpm with this requirement suggests that such a package already exists.
Trying to combine the two practices (install from package vs. install from source) is only going to cause sadness and doom.
Math.Net 3.7.0 Release Notes on nuget mention a CUDA native provider.
Control.UseNativeCUDA();
throws a DllNotFoundException for MathNet.Numerics.CUDA.dll. For the MKL-provider i need to install an extra NuGet-Package. Is there no package for the CUDA.dll yet? Or what do i have to install?
I'm using MathNet on linux with mono.
You are right. Currently there is no NuGet package available.
Also note that the CUDA support is not stable (alpha) yet.