I am using Conda with Nexus and having issues with files that are quarantined. When I run conda install package_name, sometimes I get errors that cause the conda command to fail.
Ex:
CondaHTTPError: HTTP 403 REQUESTED ITEM IS QUARANTINED for url <https://nexus.xxxx.com/repository/XXXX_CONDA_BASE/linux-64/openssl-1.1.1i-h27cfd23_0.conda>
Is there a way to run Conda commands with Nexus repo's to ignore quarantined files, find another version, and continue to run? My current workaround is to include or exclude these specific quarantined versions as I find them. This can become cumbersome when there are several quarantined files in one install command, especially likely when there is a large list of dependencies.
I was hoping to find a better solution, but for now I found some workaround way to fix this.
I added an item to the conda pinned file with a version of openssl that has been released from quarantine.
...
openssl=1.1.1h
...
Another option available is to add this same package and version to every conda install command I run.
A third option is to include this command instead: --no-update-deps, but this may be overkill as it may affect other packages and versions selected by conda.
Related
I have developed a python script and want to put it in a RPM package. The only problem is that this script uses ovirtsdk4 module, which is not one of the builtin python modules. That being said, I would have to install this module within the RPM package. I can think of two ways to approach this:
1 - Using pip3 in the %post section.
2 - Putting the python3-ovirt-engine-sdk4 in the "Requires: package " section.
However, first way does not seem quite reliable and the second doesn't seem to work properly since this package is not available on the CentOS-XXX repositories. (It belong to the ovirt repo).
Can you think of a better way to approach this or am I missing anything?
Many thanks.
The fact that the package is not in the CentOS repositories should not cause any problem, just make sure that you can download from the ovirt repository, then the update should run normally.
Test first manually if you can yum install python3-ovirt-engine-sdk4.
EDIT: don't install using pip3, because then you cannot manage the dependencies with rpm. You had the right intuition trying to use the rpm dependencies.
Good afternoon,
I am currently building an RPM that has some requirements I have not found answers to on the web. I have narrowed this down to a single question.
Normally when I run an install from command line, one of the steps has me run the following command yum groupinstall "Compatibility libraries" which installs 32-bit compatibility libraries on my 64-bit desktop. I am wondering if there is a way to accomplish this in the Requires: field of my RPM-spec file, as I have only found a way to require very specific RPM's for dependencies?
I could always add in the 10-15 individual packages that get installed with yum groupinstall "Compatibility Libraries", but I was hoping there was a better option.
Description of RPM:
My RPM is very basic in nature. It will untar multiple tar files into various locations, overwrite files throughout the main install directory, install compatibility libraries, and then proceed to startup a service.
If anyone needs more information to what I am trying to accomplish please let me know. Thank you.
You can only require specific packages, not groups, in your Requires: lines. You should absolutely not run yum in your %post script, because then (a) you are then hiding your dependencies, and nobody likes to see things get installed that they didn't expect, and (b) you will probably end up getting stuck because yum in %post would need to wait for the existing yum process to exit.
For library Requires:, the rpm build process will generally figure things out for you. You still need to manually specify the appropriate BuildRequires: dependencies, which are things that are required to build the package.
If you want to update your question with more details (e.g., a link to the spec file and a description of what you're trying to do, if it's not obvious from the spec), maybe we can come up with better solutions.
Currently I am trying to install a rpm secured_soft_2.0.0.rpm and i am
unable to install it as we already have secured_soft_1.3.0 installed.
Requirement is that we need to have both the versions installed.
Complexities :
These package inturn have dependent rpm's (lot of them ) and all these
interdependent rpm's also have versions
ex: secured_soft_1.3.0 works only with packages which are of version 1.3,
and secured_soft_2.0.0.rpm work only with dependecies of version 2.0 only.
So all these dependencies also need to be reinstalled and even these
dependenies should be parallely installed, without deleting old.
Finally , both these versions contain shared libraries and these shared
lib's do not have version numbers in their name.
#rpm -ivh secured_soft_2.0.0.rpm
error: Failed dependencies:
init-class >= 1.4.17.1-1 is needed by secured_soft_2.0.0.rpm
init-connection-interface >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-logger >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
init-security >= 2.0.11.0 is needed by secured_soft_2.0.0.rpm
As i have specified we already have secured_soft_1.3.0.rpm installed and
above dependencies are also available but of different version.
So we need the to install above dependencies and also need the old version's
of dependencies for the old rpm's to work
ex : secured_soft_2.0.0.rpm has libArt.so libSec.so and so on
which are copied to /usr/lib
Similarly secured_soft_1.3.0.rpm also has libArt.so libSec.so and so on
which are already available in /usr/lib
I tried to rename the so's but still iam not able to install.
Is it possible to change the location for these so's and get the things done
Is there any way we can do it.
At the moment, iam stuck here and would need advice on this
Appreciate any help on this.
Since the programs use the same filenames, and you need to put them on the same machine, you might be able to move the older version to another directory tree and make it work there.
You can do this with many applications which do not have compiled-in pathnames.
For instance,
install the older version (this sounds like where you are starting from)
use rpm -ql for each of the packages containing unversioned executables, libraries and associated files.
use tar to capture an archive of those files, relative to /usr (but omitting directories not owned by the packages).
create a new directory, e.g., /usr/local/myapp and untar the older version there.
update configuration files in the new location as needed
For applications such as this, I would run in a script that updates PATH (and perhaps sets LD_LIBRARY_PATH) to force the program to run from the new location. You can verify if this works using tools such as strace and lsof, i.e., by looking for the files that the program opens.
Once you have the older version working properly in the new location, you can uninstall its rpms and install the new version of the application.
Caveat: If the newer package is copied from a newer version of the operating system, however, the task is likely to be beyond your ability, whether or not you choose the alternative approach of recompiling the newer packages to fit on the existing system.
Building new/custom packages is one route to recompiling the newer version. If you have the source-RPMs for each part, that is a starting point:
extract the files from the source-RPM, e.g., using a script such as unrpm (see for example HowTo: Extract an RPM Package Files Without Installing It), and
copy those extracted files to their as-expected locations in your build-tree, e.g., $HOME/rpmbuild/SOURCES and $HOME/rpmbuild/SPECS
modify the spec-file to use the alternative location
build the new/modified package using the modified spec-file.
No, out of the box, you cannot.
I'd highly recommend looking into Docker, where you can throw each one into their own container and let them take care of all their dependency problems.
I need to install a YUM package(OpenNMS) on a server that doesn't have internet access. Is there a clean way to download all dependencies on a server with internet, package it , export it and install it on the server?
Yes/no: there are some limited tools available, and a few problems.
On your server, you can use yumdownloader (or a Downloadonly plugin for yum of yum) to create a local repository of packages. With either approach, you would download the package along with its dependencies.
This process is mentioned in
Download all dependencies with yumdownloader, even if already installed?.
yumdownloader vs repotrack
There is a caveat: my experience is that the tools can be confused by the presence of existing packages on your server (i.e., installed) and will often overlook those in the actual download. One way to work around this is to reprocess the list of downloaded files (asking for their dependencies) to check if no further files will be downloaded.
Of course, if successful, you will end up with a large number of packages (including glibc). However the alternative would be to use the dependencies known to rpm -qpR, which require a lot of work to be useful.
I'm looking into trying to find an easy way to manage packages compiled from source so that when it comes time to upgrade, I'm not in a huge mess trying to uninstall/install the new package.
I found a utility called CheckInstall, but it seems to be quite old, and I was wondering if this a reliable solution before I begin using it?
http://www.asic-linux.com.mx/~izto/checkinstall/
Also would simply likely to know any other methods/utilities that you use to handle these installations from source?
Whatever you do, make sure that you eventually go through your distribution's package management system (e.g. rpm for Fedora/Mandriva/RH/SuSE, dpkg for Debian/Ubuntu etc). Otherwise your package manager will not know anything about the packages you installed by hand and you will have unsatisfied dependencies at best, or the mother of all messes at worst.
If you don't have a package manager, then get one and stick with it!
I would suggest that you learn to make your own packages. You can start by having a look at the source packages of your distribution. In fact, if all you want to do is upgrade to version 1.2.3 of MyPackage, your distribution's source package for 1.2.2 can usually be adapted with a simple version change (unless there are patches, but that's another story...).
Unless you want distribution-quality packages (e.g. split library/application/debugging packages, multiple-architecture support etc) it is usually easy to convert your typical configure & make & make install scenario into a proper source package. If you can convince your package to install into a directory rather than /, you are usually done.
As for checkinstall, I have used it in the past, and it worked for a couple of simple packages, but I did not like the fact that it actually let the package install itself onto my system before creating the rpm/deb package. It just tracked which files got installed so that it would package them, which did not protect against unwelcome changes. Oh, and it needed root prilileges to work, which is another main sticking point for me. And lets not go into what happens with statically linked core utilities...
Most tools of the kind seem to work that way, so I simply learnt to build my own packages The Right Way (TM) and let checkinstall and friends mess around elsewhere. If you are still interested, however, there is a list of similar programs here:
http://www.dwheeler.com/essays/automating-destdir.html
PS: BTW checkinstall was updated at the end of 2009, which probably means that it's still adequately current.
EDIT:
In my opinion, the easiest way to perform an upgrade to the latest version of a package if it is not readily available in a repository is to alter the source package of the latest version in your distribution. E.g. for Centos the source packages for the latest version are here:
http://mirror.centos.org/centos/5.5/os/SRPMS/
http://mirror.centos.org/centos/5.5/updates/SRPMS/
...
If you want to upgrade e.g. php, you get the latest SRPM for your distrbution e.g. php-5.1.6-27.el5.src.rpm. Then you do:
rpm -hiv php-5.1.6-27.el5.src.rpm
which installs the source package (just the sources - it does not compile anything). Then you go to the rpm build directory (on my mandriva system its /usr/src/rpm), you copy the latest php source tarball to the SOURCES subdirectory and you make sure it's compressed in the same way as the tarball that just got installed there. Afterwards you edit the php.spec file in the SPECS directory to change the package version and build the binary package with something like:
rpmbuild -ba php.spec
In many cases that's all it will take for a new package. In others things might get a bit more complicated - if there are patches or if there are some major changes in the package you might have to do more.
I suggest you read up on the rpm and rpmbuild commands (their manpages are quite good, in a bit extensive) and check up the documentation on writing spec files. Even if you decide to rely on official backport repositories, it is useful to know how to build your own packages. See also:
http://www.rpm.org/wiki/Docs
EDIT 2:
If you are already installing packages from source, using rpm will actually simplify the building process in the long term, apart from maintaining the integrity of your system. The reason for this is that you won't have to remember the quirks of each package on your own ("oooh, right, now I remember, foo needs me to add -lbar to its CFLAGS"), as the build process will be in the .spec file, which you could imagine as a somewhat structured build script.
As far as upgrading goes, if you already have a .spec file for a previous version of the package, there are two main issues that you may encounter, but both exist whether you use rpm to build your package or not:
A patch that was applied to the previous version by the distribution does not apply any more. In many cases the patch has already been applied to the upstream package, so you can simply drop it. In others you may have to edit it - or I suppose if you deem it unimportant you can drop it too.
The package changed in some major way which affected e.g. the layout of the files it installs. You do read the release notes notes for each new version, don't you?
Other than these two issues, upgrading often boils down to just changing a version number in the spec file and running rpmbuild - even easier than installing from a tarball.
I would suggest that you have a look at the tutorials or at the source package for some simple piece of software such as:
http://mirror.centos.org/centos/5.5/os/SRPMS/ipv6calc-0.61-1.src.rpm
http://mirror.centos.org/centos/5.5/os/SRPMS/libevent-1.4.13-1.src.rpm
If you have experience in buildling packages from a tarball, using rpm to build software is not much of a leap really. It will never be as simple as installing a premade binary package, however.
I use checkinstall on Debian. It should not be so different on CentOS. I use it like that:
./configure
make
sudo checkinstall make install # fakeroot in place of sudo works usally for more security
# install the package generated