I've created repository where I store my own packages.
System uses my and some other public repositories.
So now I've a package in my repo which I want to be as an update for some other package from another repository.
The repositories are rpm package based.
Is it generally possible to mark my own package to update another package ?
(I would have made this a comment on the previous answer, but its too long.)
There's a problem with using the same package name and just bumping the version number.
Eventually the original package may increase its version number past what you're using, in which case someone may do a yum update and end up upgrading back to the original package.
To avoid this problem, you can change the package name slightly, and add some Obsoletes and Conflicts dependencies to your spec file. The Obsoletes dependency allows the original package to be upgraded to your package, while the Conflicts keeps the original package from being installed at the same time as your package.
This should keep an upstream version bump from clobbering your changes.
See http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-dependencies.html
Going to answer to my own question, yes yum treats all repositories equally. So all I need to do was setting package name the same and increased version number.
To test it you just need to create a yum repo and setup yum to use your repository for more info look here
Related
We have a private nexus repository and publishing all the npm modules there. We have Module A and Module B, B is dependent on A. Here I am getting an issue with installing the latest SNAPSHOT version. For example:
Module A has published versions like
'1.0.0-SNAPSHOT', '1.0.1-SNAPSHOT', and '1.0.0'
In Module B package.json, I added the dependency like
"Module A": "^1.0.0-SNAPSHOT"
As I mentioned "^" in the dependency, it should install the latest version (i.e, 1.0.1-SNAPSHOT), But I am not sure why it is installing '1.0.0' instead '1.0.1-SNAPSHOT.
Your help would be greatly appreciated. Thanks in Advance.
Avoid releasing and using snapshot dependencies. When you publish a release, it should not contain -SNAPSHOT. Referring to a proper release is mandatory in order to be sure you are testing/executing the right code without side effects due to regression problems. You need to know in every moment which version you are using, that is very important, so relying on latest versions of your modules might not be the best solution, it doesn't worth it either if you are precise with major, minor and patch bits in order to avoid breaking changes or unexpected behaviors.
If you really need to develop them together you can use npm link command instead.
For example I have Intellij Idea installed on my Arch Linux system. Intellij Idea has built in updater and assume that I's already updated Intellij Idea with that built in Intellij Idea updater. But when I perform "yaourt -Syu" corresponding Intellij Idea's package is still shown in list of packages that are waiting for updates. So how can I say yaourt or pacman (or any other pacman wrapper that may have such feature) that package is already updated?
If you just want that Feature I would recommend yay to you, it has that Feature to skip an installation of a Packet! As discussed here you shouldn't use yaourt anymore.
If you don't want that update Problem at all install jetbrains-toolbox which will manage your installed IDEs, if you are using more than one, so you only have to update the toolbox once in a while.
The problem is that you haven't updated it. You've overwritten the copy pacman knows about, with an untracked copy from elsewhere.
So, of course, pacman's metadata will not be updated. In order to circumvent this you'd need to create a custom dummy package which provides intellij, while managing it entirely yourself.
But what is wrong with using the official repository package https://www.archlinux.org/packages/?name=intellij-idea-community-edition and just letting pacman update it for you?
Given the news that npm 5.7.0 had some issues in production, I'm wondering if it's possible to blacklist a package version either in package.json or on the machine level perhaps in .npmrc or .yarnrc.
The behaviour I'm expecting is that upgrades are possible, so this is not a fixed semver version. SemVer has intentionally avoided defining version skipping in the spec because,
SemVer is meant to communicate what type of changes have occurred, not
'how much' change has occurred. If a user wants to know the details of
how much has changed, they should look at the changelog. A long
changelog tells them it's a big update.
But as a user I may know beforehand that I never want this version. For example, never use 5.7.0 but 5.7.1 is ok.
If you have package A that depends on B and B has a known bad version, you can define a version range with a hole in it. See last paragraph of https://docs.npmjs.com/misc/semver. I am not aware of any way to globally black-list such a version on your system however, so if you install A and it doesn't have a version hole on its dependency on B, you might have gotten the bad version, but in the example you state above, the offending version was pulled from publication as the news was released regarding the defect.
One thing you can do is purge your cache of any bad package versions to insure that they can't be used to resolve dependencies.
After updating my NPM to the latest version (from 3.X to 5.2.0) and running npm install on an existing project, I get an auto-created package-lock.json file.
I can tell package-lock.json gives me an exact dependency tree as opposed to package.json.
From that info alone, it seems like package.json is redundant and not needed anymore.
Are both of them necessary for NPM to work?
Is it safe or possible to use only the package-lock.json file?
The docs on package-lock.json (doc1, doc2) doesn't mention anything about that.
Edit:
After some more thinking about it, I came to the conclusion that if someone wants to use your project with an older version of NPM (before 5.x) it would still install all of the dependencies, but with less accurate versions (patch versions)
Do you need both package-lock.json and package.json? No.
Do you need the package.json? Yes.
Can you have a project with only the package-lock.json? No.
The package.json is used for more than dependencies - like defining project properties, description, author & license information, scripts, etc. The package-lock.json is solely used to lock dependencies to a specific version number.
package-lock.json: records the exact version of each installed package which allows you to re-install them. Future installs will be able to build an identical dependency tree.
package.json: records the minimum version you app needs. If you update the versions of a particular package, the change is not going to be reflected here.
If your question is if lock file should be committed to your source control - it should. It will be ignored under certain circumstance.
I found it bloating pull requests and commit history, so if you see it change, do a separate commit for it.
What is the best way to ensure that all developers and the build server are using the latest version of FAKE?
If a build.cmd like the one from FSharp.Data is used, the developer will not be on the latest until they delete FAKE from the packages folder or just delete the whole packages folder.
If you add FAKE as a dependency in .nuget\packages.config, your build.fsx script must include the version information and be updated each time you change versions. You will not automatically get the latest version.
With NuGet 2.8.1 you can remove the "if not exists" parts - NuGet will check (very slowly) if the latest FAKE is installed.