I'm using CentOS 7 64bit. I'm trying to download multiple packages with their dependencies using yumdownloader. However I'm facing the problem that packages that I do not need are getting downloaded.
When I'm installing a package using yum install <package> only one package is getting installed: either x86_x64 (if available), or i686 (if 64bit is not available) or noarch. I'm trying to mimic the same behavior to download only the best matching packages with yumdownloader. However this does not work as expected and both x86_x64 and i686 are getting downloaded for packages that have 2 architectures available. Adding --archlist=x86_64 does not make any difference. Setting multilib_policy=best in a config file does not make any difference either.
I also checked repoquery tool. If I set --archlist=x86_64 then only x86_64 packags would be listed. Those that have only i686 or noarch versions will not be picked up. If I set --archlist=x86_64,i686,noarch then the result is similar to yumdownloader, i.e. multiple architectures are being picked up.
Is there a way to list or download only best matching package?
The only option I see is to do it completely manually - prepare lists using repoquery and remove duplicates. But I would prefer to find more neat and robust approach.
What you can do, is use the standard yum option for excluding packages. It is "inherited" by yumdownloader.
Example:
yumdownloader libX11 --archlist=x86_64 --exclude="*.i686"
Note that i686 is sort of "subset" to x86_64 due to multilib, and especially applies to libraries (nearly all have i686 equivalent). Make sure you won't have any software that actually requires i686 libraries later on... The only notable example of such i686-only software I've seen is steam.i686 (there is simply no x86_64 version), but then again who plays that on RHEL? (aside from myself).
Related
The obsolete packages repository https://vault.centos.org/4.0/os/x86_64/CentOS/RPMS/ contains one I would like to install on CentOS/Rocky 8.
I am having problems with basic libraries such as libcrypto.so.4 and libssl.so.4 that conflict with the new system.
openssl-1.X doesn't allow openssl-0.X while the reverse is possible
I tried to install openssl-0.X which contains the missing dependencies but this leads to a broken system when I uninstall current openssl-1.X
I also tried to create symbolic links for the missing libraries to the existing ones
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I'm looking into running Swift on a Ubuntu 16.04 server. However I want to be certain about where I should install the toolchain.
From swift.org:
If you installed the Swift toolchain on Linux to a directory other than the system root, you will need to run the following command, using the actual path of your Swift installation...
Then from Kitura's Setting Up instructions:
After extracting the .tar.gz file, update your PATH environment variable so that it includes the extracted tools:
$ export PATH=<path to uncompressed tar contents>/usr/bin:$PATH
Where is the best place to install these type of things? In the past I would rely on apt-get or installation scripts provided by maintainers but this doesn't seem to be the case with Swift.
Are there any benefits or disadvantages to not installing it at the system root?
Note: This question borders on "best practices", which I believe is frowned upon here. I'm sorry about that; I've googled around and this seems to be something that people know implicitly. However, I don't yet and need some guidance
The versions of the software in your system root - in /usr/bin, /usr/share, /usr/lib, etc. - are carefully coordinated by the maintainers of your distribution to handle all reasonable dependencies. The maintainers also keep the software up-to-date with bug fixes.
When you need to install software that isn't supplied by your distribution, it's best to install it in a separate directory, such as /opt (in your case, one possibility is /opt/swift-3.1.1). This will avoid overwriting existing installed software (in your case, /usr/bin/lldb and /usr/lib/lldb) with something that's possibly incompatible with other software. And it will make it easy to uninstall (just rm -r /opt/swift-3.1.1 rather than having to get a list of files from the original tarball that are potentially strewn all over /usr).
There is some extra effort: you'll need to add /opt/swift-3.1.1/usr/bin to your PATH1. With some software, you'll need to add the directory containing dynamic library files to LD_LIBRARY_PATH. The software's installation instructions typically explains what you need to do.
[1]An alternative to changing PATH is to add a symlink to each new executable, in a directory that's already in your PATH. GNU Stow can help you do this.
I want to setup a cross compile environment on Linux for the Raspberry Pi 1.
Especially I want to try bleeding edge version, i.e. Raspbian testing + Qt5 dev branch.
This question:
How can I create a modern cross compile toolchain for the Raspberry Pi 1?
...explains how to get a gcc compiler, which can create code for the Raspberry Pi 1. Are there changes necessary on Raspbian itself to use it? If so, which ones?
A full toolchain is what you need
A toolchain is a set of tools working together to generate binaries for your system. Depending on how you build your toolchain, it might end up in being only functional for your own image, that's not, in fact a problem, you just clone your image and upgrade it at will.
First, understand what you need:
Functional flagship system. This is your reference board and your reference distro bundle, your packages and your stuff. You might want a standard Raspbian or you might want some extra stuff, like OpenCV or less stuff like removing Xorg. You say you want bleeding edge, so fit your taste.
Sysroot. Ideally this is a copy of your Functional Flagship System with the added development headers. In my case its exactly the same, for Raspbian this is an image of your second partition, the one that hosts /.
Cross compiler. This is a compiler that generates code for ARM while running on x86 or x86_64. This is generally a specialized gcc.
Cross compiled qmake. For Qt you need a cross qmake, this is a qmake that will generate Qt binaries and uses things you need to generate your arm Qt software.
ARM Qt libraries. This is part of your Functional Flagship System, I just enumerate it here for the sake of clarity. They will get compiled by you using your sysroot and your cross compiler.
Qt Libraries for Cross Compiling. This are a product of the steps you will follow when generating your cross compiling qmake and ARM Qt Libraries. This will be installed in your host x86 system.
So how do you get all of this?
Gather Your Very Own Toolchain
Functional Flagship System (FFF). Just get your raspbian image and install your additional software at will, whatever you want to be in, just install it on a live Raspberry.
Sysroot. Once you have your FFF, then use dd to generate an image of your second raspbian partition. Get your card off, insert it into a x86 system and use dd. There are other ways using mount and offsets but this is a lot simpler.
Cross compiler. Unless you really know what you are doing, just refrain from creating it yourself. There are functional cross compilers.
Qmake for cross compiling, ARM Qt and Qt Libraries. This is the interesting part...
Cross Compiling Qt 5
You can go as bleeding edge as you please with Qt as you get it from git. As this is not really a Wiki I will just enumerate the steps. This guide explains it with a lot more detail.
Get your FFF, image and cross compiler working.
git clone your Qt, pick a tag (version)
mount your sysroot
Get ia32-libs if you are under x64
Compile qtbase then make install. IMPORTANT: After you get qtbase it generates it's own qmake, use it from now on.
Use the generated and installed qmake from qtbase to build any other Qt module you want.
Remember to use make install on all Qt modules you build. All these 'installs' will copy those binaries to your sysroot.
Get your Qt into your FFF. Either you copy the folder and avoid messing with permissions, or more easily just umount your sysroot, then use dd to dump the modified image to the very same physical partition you got it from. These are the ARM Qt Libraries.
When building qtbase it will install some stuff into your own x86 system. This is Qmake for cross compiling, use it into Qt Creator to generate cross compiled binaries along with your cross compiler.
Some notes nobody tells you
There seem to be no toolchains ready to download. This is because they depend a lot on your specific setup.
Do not use system or regular qmake to cross compile. Use your generated qmake, as it fits perfectly with your FFF, it has paths and other specific stuff baked in.
I repeat, do not bother creating your cross compiler
What if you need additional development files? Install them on your FFF, then copy your partition to have your new sysroot.
Yes, you can auto-deploy with Qt and even debug remotely on a live Pi.
Installing a bleeding edge development system/toolchain is a bit of a problem... It is a moving target. The following steps did work for me March 2015. If they still 100% work or how long they will work... But if one have read and understood the following 'walktrough' it should not be difficult to adjust the process for future Raspian or Qt5 versions.
Fist step should be to update Raspian. I upgraded to testing. To do this, change the repository in /etc/apt/sources.list to:
deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib
non-free rpi
Followed by the usual 'apt-get update, apt-get upgrade, apt-get dist-upgrade'. Or an analogue aptitude command. After this step one has upgraded to the most recent Raspian. With all the risks and benefits of a testing release.
Next a couple of packages needs to be installed. Probably not all necessary, e.g. xcb does not work on a RPi, and the RPi hat its own set of opengl files. But some Raspian packages don't know this and might pull them in anyways. The packages below allow to compile a Qt5 with QMultimedia and
apt-get install -y "^libxcb.*" libx11-xcb-dev libglu1-mesa-dev libxrender-dev libxi-dev libicu-dev libxslt1-dev
apt-get install -y libssl-dev libxcursor-dev libxrandr-dev libfontconfig1-dev libcap-dev libbz2-dev libgcrypt11-dev
apt-get install -y libpci-dev libnss3-dev libxtst-dev libasound2-dev libcups2-dev libpulse-dev libudev-dev
apt-get install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libproxy-dev libmtdev-dev libts-dev
apt-get install -y libxkbcommon-x11-dev libxkbcommon-dev libinput-dev libgbm-dev libjpeg8-dev libgif-dev libopenjpeg-dev
apt-get install -y libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev sqlite3 libsqlite3-dev libwayland-dev
apt-get install -y libdirectfb-dev libegl1-mesa-dev libsystemd-journal-dev libharfbuzz-dev xutils-dev libcairo2-dev
apt-get install -y libffi-dev libpam0g-dev
The next and most important step is also the most unpleasant one. A couple of libraries in Raspian are symbolic links with absolute paths. This is bad since those libraries are later on not found when Qt5 is compiled. All symlinks of relevant libs must be turned into symlinks with relative paths. With Google's help a script can be found, which did this almost automatically, but for some reason it did not work for me. Therefore I did it manually. If I have to do this more often, I certainly will write my own. This is also the step, which is most likely to break. Library versions change... so don't blindly copy/paste the commands below.
Not all of the libs below are necessary to compile Qt5, but all of them could be a problem eventually. After this step the Raspberry Pi is ready to be used. Next step is to compile and install Qt5.
EDIT: One of the side effects of writing such a mini-tutorial: One thinks again about certain things one has done. There is a much easier way to convert absolute links into relative links: symlinks.
So:
apt-get install symlinks
And then in /usr/lib/ on the Raspberry Pi:
symlinks -cr .