Does anybody know what would happen if a package gets installed, while the old package remains installed? The thing is that the command rpm -e <rpm_package> will uninstall and delete the old package. In my case, I want to keep the old package as a backup and I don't want it to get erased.
Is it possible to keep the old package available in the file system(without deleting it) while having installed the new one?
Thanks in advance!
Yes, this is possible. It is not documented, but when you install an RPM with both the
--nodeps and --force options
It turns out yum really does disable ALL dependency logic
This is the other way to get into the state of having duplicates besides:
you terminate rpm during the transaction.
If you don't believe me give it a try on a CentOS 7 server. It's possible this behavior has changed in dnf - after all it was meant to be an upgrade to yum. That would not shock me.
No, it is not possible.
It can happen that you have two package of the same name. But that is only possible when:
you terminate rpm during the transaction. You can then remove the correct one using full NEVRA. I.e., rpm -e bash-5.1.8-2.fc35.x86_64
when packages are multilib. I.e., one is i386 and the other x86_64
If you want to keep backups then I recommend either using 'local' plugin https://dnf-plugins-core.readthedocs.io/en/latest/local.html Just be aware that it can consume a lot of storage.
Or even Red Hat Satellite, which allows you easy rollbacks. But that is likely big beast for your needs.
Related
Our CI pipeline publishes wheels for branches that have a version of
<base version>-dev<timestamp>+<branch name>.p<pipeline id>
So if I am working on cool-stuff on in the xyzzy branch, it might upload a wheel for version 1.2.3.dev202211221111+xyzzy.p1234
Somebody else, working in the foobar branch, might cause 1.2.3.dev202211221115+foobar.p1235 to be created.
How can I get pip to install the latest version from the xyzzy branch? I tried pip install cool-stuff>1.2.3.dev*+xyzzy but it complained that it could not find a matching version (even though the available versions that it listed included a +xyzzy tag.)
pip install cool-stuff==1.2.3.dev202211221111+xyzzy.p1234 did work, but I would prefer not have have to update the time stamp and pipeline number each time. I am hoping to put cool-stuff >= <magic> in my config file and just run pip install -e . whenever I need new dependencies.
What format do I need to use here?
As far as I know, it is not possible. I can not think of a workable solution that would be based on the version string only. The "local" part of the version string (in other words the part after the plus sign +) can not be used to differentiate between two releases as you intend to.
If I were in your situation, I think I would investigate a solution where the CI/CD pipelines generate distributions with a name customized according to the git branch. For example in your case the pipelines should generate wheels for Library-foobar or Library-xyzzy, depending on what branch is currently being worked on (while still keeping the same top-level import names of course). This assumes that you can customize your pipelines and processes deeply enough to support such a workflow.
I maintain a conda-forge package called switch_model. Subsequent to our last release (2.0.5), one of the packages we depend on has made an incompatible change. So I am trying to publish a post-release, 2.0.5.post2, that requires an older version of that package.
I've managed to create the post-release on PyPi and I can install successfully with pip. I also updated my meta.yaml for the recipe and pushed that to github (https://github.com/conda-forge/switch_model-feedstock/blob/master/recipe/meta.yaml).
Now, the conda-forge website at https://anaconda.org/conda-forge/switch_model identifies the latest version as 2.0.5.post2. But when I try to install to my computer using conda install -c conda-forge switch_model, it says it will install the older 2.0.5 version. If I try conda install -c conda-forge switch_model=2.0.5.post2, I get a message that it cannot be found. However, if I use conda install -c conda-forge/label/main switch_model, it installs the latest version (2.0.5.post2).
So as things stand, the new version is on conda-forge, but people who try to install my package will still get the old version with the wrong dependencies, and it won't work.
Does anyone know how to get conda to automatically install the post-release version? It's possible that I needed to fork the switch_model-feedstock repository into my personal account on github, then do a pull request back to the conda-forge account. But I'm not sure if that would have made a difference (I don't think I did that for the original 2.0.5 version), and I'm not sure how I would do it retroactively, since I've already pushed the new version of meta.yaml into the conda-forge version of the repository.
Update
By the time I finished writing this question, the 2.0.5.post2 version is now installing by default. So I may have just needed to wait until something happened in the delivery system. So my question now is, is there anything I could have done to test that the new version of the package would soon be available to users (e.g., clear some cache of available versions)? Would it make a difference if I updated the package via a pull request from another repository instead of pushing directly to the conda-forge version?
By the time I finished writing this question, the 2.0.5.post2 version is now installing by default. So I may have just needed to wait until something happened in the delivery system.
Packages can take some time (~1 hour) to actually be installable through conda, even if they appear on anaconda.org.
So my question now is, is there anything I could have done to test that the new version of the package would soon be available to users (e.g., clear some cache of available versions)?
Not completely sure what's being asked here
If you're asking if you can force your users to update their version, no.
If you wish to ensure the build is not broken, you can run its tests during the build process: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#test-commands
If your concern is the discrepancy between it seemingly being online and Anaconda's servers actually delivering it to users via conda, not really. Once a build passes all of the status checks that conda-forge's bots do, there are vanishingly few reasons why it would fail to be available to users later.
Would it make a difference if I updated the package via a pull request from another repository instead of pushing directly to the conda-forge version?
No, and in general it's best to, wherever possible, to stay within the infrastructure that conda-forge has already built out.
Ultimate Goal:
I'm trying to convert a binary plist file to an xml format so that I can put it in an array and grab values from it. What I'm finding via web search on this is that the command for Linux comes from libplist.
Problem: I ran "yum install libplist" and it told me libplist is already installed and latest version. I've read that if I enter the following command:
plutil -i /mypath/file.plist > /mypath/file.xml.plist
That this will help accomplish my ultimate goal. However, when I do this only a blank file called file.xml.plist is created. Further, with this command and any other command involving plutil, I get a "bash: plutil: command not found. . ." error. Is libplist seemingly not installed (even though it says it is) or why would I repeatedly get this error? Thanks for your help.
You can use yum to look for a package knowing the binary you want. For instance, if I want to install the package that provides plutil, I simply run this command:
$> yum provides plutil
Unfortunately, the result is No matches found... But you say you read that the libplist package provides this tool. Maybe it was renamed ? Let's use repoquery for this (if you don't have it, yum provides repoquery tells you that you need to install yum-utils).
$> repoquery --list libplist
/usr/bin/plistutil
/usr/lib/libplist++.so.3
/usr/lib/libplist++.so.3.0.0
/usr/lib/libplist.so.3
/usr/lib/libplist.so.3.0.0
/usr/share/doc/libplist
/usr/share/doc/libplist/AUTHORS
/usr/share/doc/libplist/COPYING.LESSER
/usr/share/doc/libplist/README
And what I see is that a program called plistutil was installed with this package !
I've never used plutil, so I can't tell you for sure plistutil is the program you want (but it probably is). What I wanted to do instead with this post is to show how you can use yum to install the packages you need !
I ran across this thread while Googling for the same thing myself. After looking at a few solutions for my own company (Screenplay) I decided to fork and iterate on a open-source, cross-platform, drop-in replacement for plutil:
https://github.com/screenplaydev/plutil
It's forked from Facebook's xcbuild (a tool developed by them to build xcode projects on Linux), but stripped down to just provide plist-editting functionality. That way you won't need to maintain separate code-paths for Mac and Linux environments.
Hope that's helpful!
Maybe it's because I'm new to shared environments where I have no root access or the dpkg/apt family of tools, but I wanted to install from source (for instance, gcc/gdb), possibly by using wget to grab the tarball, unpack it, and point configure --prefix=$HOME, before calling make; make install, but I'm having some issues. Namely, the whitelist (obvious), and secondly the configure step is giving me trouble.
Can someone walk me through this process? Pythonanywhere comes with make, so it's not as if they don't want you doing this.
EDIT
Perhaps gcc/gdb may not be the best example -- together they are close to half the 500MB allotment for free accounts.
Any pure python modules will install with ease. Unfortunately you can't install modules that require a compiler. The Python Anywhere staff is generally very accommodating to get packages requested installed to the battery's included for all to enjoy.
Feel free to make a request to the PA forum
or
Email the staff: support#pythonanywhere.com
For clarity. To install a pure python module you just use
pip-3.2 install --user <package_name>
Change 3.2 as needed for the Python version you want and of course change <package_name> to your desired package.
The rpm command provides three main operations for upgrading and installing packages:
Upgrade
An upgrade operation means installing a new version of a package and removing all previous versions of the same package. If you have not installed a package previously, the upgrade operation will install the package.
Freshen
A freshen operation means to install a new version of a package only if you have already installed another version of the package.
Install
An install operation installs a package for the first time. It also, through special command-line parameters, allows you to install multiple versions of a package, usually not what we want. So, in the vast majority of cases, you want to run the upgrade operation for all package installations.
Should normally install packages with rpm -U, not rpm -i. One of the main reasons is that rpm -i allows you to install multiple instances of the same (identical) package.
Is this the standard conclusion or
should I stop installing the second instance of the package along with the first instance by writing any wrapper script or by adding code in spec file section.
If 2 point is the answer how can achieve this. Please guide me about this confusion.
Assuming you only every want one version of an RPM installed at once, then yes use "rpm -U".
Creating an RPM that can have multiple versions installed requires that all common files between the versions are identical. This frequently happens, so you may get this behaviour "by default".
You can also prevent multiple versions with the following in you spec:
Conflicts : %{name} < %{version}