Dnf removes many dependencies along mariadb-config and mariadb-common - mariadb

Working on Fedora 26. Had mariadb 10.1.26 installed but I need some features available on 10.2.2.
To install MariaDB-server 10.2 from MariaDB repositories, it seems necessary to remove mariadb-config and mariadb-common, since some files are conflicting:
# dnf install MariaDB-server
Last metadata expiration check: 0:39:56 ago on Thu 21 Dec 2017 02:25:04 AM CET.
Dependencies resolved.
===================================================================================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================================================================================
Installing:
MariaDB-server x86_64 10.2.11-1.fc26 mariadb 24 M
Installing dependencies:
MariaDB-client x86_64 10.2.11-1.fc26 mariadb 11 M
MariaDB-common x86_64 10.2.11-1.fc26 mariadb 79 k
galera x86_64 25.3.22-1.fc26.fc26 mariadb 8.9 M
perl-DBI x86_64 1.636-4.fc26 fedora 732 k
perl-Math-BigInt noarch 1.9998.11-1.fc26 fedora 193 k
perl-Math-Complex noarch 1.59-395.fc26 updates 101 k
Transaction Summary
===================================================================================================================================================================================================================
Install 7 Packages
Total size: 45 M
Installed size: 214 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] MariaDB-server-10.2.11-1.fc26.x86_64.rpm: Already downloaded
[SKIPPED] perl-DBI-1.636-4.fc26.x86_64.rpm: Already downloaded
[SKIPPED] MariaDB-client-10.2.11-1.fc26.x86_64.rpm: Already downloaded
[SKIPPED] MariaDB-common-10.2.11-1.fc26.x86_64.rpm: Already downloaded
[SKIPPED] perl-Math-BigInt-1.9998.11-1.fc26.noarch.rpm: Already downloaded
[SKIPPED] galera-25.3.22-1.fc26.fc26.x86_64.rpm: Already downloaded
[SKIPPED] perl-Math-Complex-1.59-395.fc26.noarch.rpm: Already downloaded
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
file /etc/my.cnf from install of MariaDB-common-10.2.11-1.fc26.x86_64 conflicts with file from package mariadb-config-3:10.1.26-2.fc26.x86_64
file /usr/lib64/mysql/plugin/dialog.so from install of MariaDB-common-10.2.11-1.fc26.x86_64 conflicts with file from package mariadb-common-3:10.1.26-2.fc26.x86_64
file /usr/lib64/mysql/plugin/mysql_clear_password.so from install of MariaDB-common-10.2.11-1.fc26.x86_64 conflicts with file from package mariadb-common-3:10.1.26-2.fc26.x86_64
If I try to remove the concerned packages mariadb-config and mariadb-common, DNF needs to remove an impressive list of unrelated packages, like shotcut, blender, mplayer. Sample:
Removing:
mariadb-config x86_64 3:10.1.26-2.fc26 #updates 1.3 k
Removing dependent packages:
OpenImageIO x86_64 1.7.17-2.fc26 #updates 9.3 M
armadillo x86_64 7.900.1-1.fc26 #fedora 47 k
blender x86_64 1:2.79-1.fc26 #updates 143 M
dvdauthor x86_64 0.7.2-2.fc26 #fedora 609 k
flowblade noarch 1.14-3.gitcad77b5.fc26 #unitedrpms 20 M
gdal-libs x86_64 2.1.3-1.fc26 #fedora 19 M
gmic x86_64 1.7.2-3.fc26 #fedora 14 M
kdenlive x86_64 17.08.3-2.fc26 #unitedrpms 59 M
kf5-kfilemetadata x86_64 5.38.0-1.fc26 #updates 701 k
ladspa-calf-plugins x86_64 0.0.60-5.fc26 #fedora 0
lapack x86_64 3.6.1-4.fc26 #fedora 11 M
libspatialite x86_64 4.3.0a-4.fc26 #fedora 11 M
lives x86_64 2.8.7-1.fc26 #rpmfusion-free 8.8 M
mariadb-common x86_64 3:10.1.26-2.fc26 #updates 393 k
mariadb-libs x86_64 3:10.1.26-2.fc26 #updates 3.6 M
mkvtoolnix x86_64 17.0.0-1.fc26 #updates
Does mkvtoolnix really depends on mariadb-config?
# dnf deplist mkvtoolnix | grep -i maria
Last metadata expiration check: 0:44:36 ago on Thu 21 Dec 2017 02:25:04 AM CET.
#
It seems not... How can I install MariaDB-server (with caps = 10.2) without removing unrelated packages (which I actually want to keep and not remove/reinstall)?

Finally succeeded:
Removed mariadb-* with yumex (GUI)
Removed mariadb-server with dnf (CLI)
Installed MariaDB-* (10.2) with dnf
For unknown reason, Yumex did not remove unrelated packages while dnf would have.

Related

Cannot install R in RHEL 8.5 using a Dockerfile script

I can install R and RStudio with no problem from the RHEL 8.5 CLI.
However, when I try to automate the installation process using a Dockerfile following the instructions at https://docs.rstudio.com/resources/install-r-source/, I get the following error when trying to pass the value defined in my "export R_VERSION=4.0.2" instruction:
[ 6/11] **RUN yum install -y R-${R_VERSION}-1-1.x86_64.rpm --nogpgcheck**:
#9 0.957 Last metadata expiration check: 0:00:04 ago on Fri Mar 25 19:22:44 2022.
#9 1.066 Can not load RPM file: R--1-1.x86_64.rpm.
#9 1.071 Could not open: R--1-1.x86_64.rpm
executor failed running [/bin/sh -c yum install -y R-${R_VERSION}-1-1.x86_64.rpm --nogpgcheck]: exit code: 1
Help is appreciated.
sh-4.4# **yum install -y R-${R_VERSION}-1-1.x86_64.rpm --nogpgcheck**
Last metadata expiration check: 0:02:02 ago on Fri Mar 25 15:56:49 2022.
Dependencies resolved.
=============================================================================================================================================================== Package Architecture Version Repository Size
===============================================================================================================================================================Installing:
R-4.0.2 x86_64 1-1 #commandline 58 M
Upgrading:
glibc x86_64 2.28-164.el8_5.3 ubi-8-baseos 3.6 M
glibc-common x86_64 2.28-164.el8_5.3 ubi-8-baseos 1.3 M
glibc-minimal-langpack x86_64 2.28-164.el8_5.3 ubi-8-baseos 58 k
......
...........
.............
..................
**Complete!**
sh-4.4# r
sh: r: command not found
sh-4.4# /opt/R/${R_VERSION}/bin/R --version
R version 4.0.2 (2020-06-22) -- "Taking Off Again"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.

.NET Core 3.1 installed on Fedora 32 but it doesn't work

The dotnet program is in the directory '/usr/bin/dotnet'. When I switch to that directory and run dotnet new web, all I get is:
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:> https://aka.ms/dotnet-download
Suggestions?
When I switch to that directory
Don't run dotnet new from within the /usr/bin directory. What's in there is a symlink to the actual binary so that it's available on your PATH. So /usr/bin/dotnet will likely point to a location such as /usr/lib64/dotnet/dotnet. You should be able to run dotnet from any location that your user has access to.
It's likely that the problem, is related to the fact that dotnet-sdk-3.1 is now available in the official fedora repo as well as the microsoft repos so you may have a mix of binaries that are incompatible.
I had a similar problem today where I had a mix of packages like the following installed:
dotnet-apphost-pack-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-host x86_64 3.1.8-1.fc32 #updates
dotnet-hostfxr-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-runtime-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-runtime-deps-3.1 x86_64 3.1.8-1 #packages-microsoft-com-prod
dotnet-sdk-3.1 x86_64 3.1.402-1 #packages-microsoft-com-prod
dotnet-targeting-pack-3.1 x86_64 3.1.8-1.fc32 #updates
...
it turned out the packages I'd installed before from Microsoft's repo don't play well with the Fedora ones (the ones with .fc32).
To solve this I simply needed to uninstall all my dotnet packages: sudo dnf remove dotnet-* then set the priority of the fedora repos to be higher than microsofts. This is done by editing the affected repos such as /etc/yum.repos.d/fedora.repo and adding:
priority = N (where N is a number between 1 and 99)
I set fedora's repos to priority 1 (they really should do that anyway) and microsofts repos to 5.
Then simply install again, this time it will pull down from Fedora repo:
sudo dnf install dotnet-sdk-3.1
And now it's more like:
dotnet-sdk-3.1 x86_64 3.1.108-1.fc32 #updates
dotnet-apphost-pack-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-host x86_64 3.1.8-1.fc32 #updates
dotnet-hostfxr-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-runtime-3.1 x86_64 3.1.8-1.fc32 #updates
dotnet-targeting-pack-3.1 x86_64 3.1.8-1.fc32 #updates
...
and everythings working as it should be. Running dotnet --list-sdks outputs: 3.1.108 [/usr/lib64/dotnet/sdk]
I had to do this:
sudo mv /usr/share/dotnet/sdk/* /usr/lib64/dotnet/sdk/
And similar after that when i do dotnet --list-sdks it all works
but I did have to reset my terminal / Restart my IDE (rider)

R wrong ELF class errors while install.packages is compiling

I'm running Ubuntu Budgie 64 bit:
lsb_release -a:
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
lscpu:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 76
Model name: Intel(R) Celeron(R) CPU N3050 # 1.60GHz
Stepping: 3
CPU MHz: 2160.000
CPU max MHz: 2160.0000
CPU min MHz: 480.0000
BogoMIPS: 3200.00
Virtualization: VT-x
L1d cache: 24K
L1i cache: 32K
L2 cache: 1024K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
I did a fresh install of R 3.5 (r-base & r-base-dev) by following the directions here: https://cran.cnr.berkeley.edu
Everything seems to be working,
R
R version 3.5.1 (2018-07-02) -- "Feather Spray"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
However, when I go to install new packages (e.g. install.packages("ggplot2")) the compilation fails with the following error:
/usr/bin/x86_64-linux-gnu-ld: /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so:
error loading plugin: /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so:
wrong ELF class: ELFCLASS64
collect2: error: ld returned 1 exit status
It has failed with this error for the other packages I have tried installing (dplyr, Rcpp) also.
So far, I have tried playing around with the gcc/g++ compilation flags in /usr/lib/R/etc/Makeconf by adding a -m64 flag. But I'm still getting the same problem.
UPDATE :
file -L /usr/bin/x86_64-linux-gnu-ld gives:
x86_64-linux-gnu-ld: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=8263ec62232df7411c36026e7e3e02afbfeb8b4f, stripped
UPDATE 2 :
I figured out that I can just go through the synaptic package manager and download packages via r-cran. For example, instead of running install.packages("ggplot2") in R, I simply run sudo apt-get install r-cran-ggplot2
Your GCC installation is screwed up.
In particular, you have 32-bit linker (x86_64-linux-gnu-ld), but a 64-bit LTO plugin liblto_plugin.so.
These are supposed to match. You should figure out which package(s) provide above two files, and install a 32-bit or a 64-bit version of each.
I recently encountered almost the same problem, except with an armhf liblto_plugin.so on an aarch64 linker. I got into this situation after I had (intentionally) installed gcc:armhf and binutils:armhf on an aarch64 host. The solution was to install the not-so-obvious package named binutils-arm-linux-gnueabihf:armhf.
Along the lines of what #Employed Russian said, you need to get the proper binutils installed. Try:
sudo apt install --reinstall binutils:amd64 binutils-x86_64-linux-gnu:amd64
If those packages aren't found or don't work, next try searching for the proper package name via apt-file just as I had to.
sudo apt install -y apt-file
sudo apt-file update
apt-file search x86_64-linux-gnu-ld
apt-file search x86_64-linux-gnu-ld.bfd

How to install two Ries KV?

Installed Riak KV in /etc/riak.
How to install another version of Riak KV on the same computer?
I have riak 2.2.0
uname -a
Linux riak-2 2.6.32-642.1.1.el6.x86_64 #1 SMP Fri May 6 14:54:05 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

Unable to upgrade r-base-core package to backports in Debian

I am trying to upgrade r-base-core from version 3.1.1-1 in Debian Jessie to version 3.3.2-1 in jessie-backports. My setup:
$ apt-cache policy r-base-core
r-base-core:
Installed: 3.1.1-1+deb8u1
Candidate: 3.1.1-1+deb8u1
Version table:
3.3.3-1~jessiecran.0 0
500 http://cran.cnr.berkeley.edu/bin/linux/debian/ jessie-cran3/ Packages
3.3.2-1~bpo8+1 0
100 http://ftp.debian.org/debian/ jessie-backports/main amd64 Packages
*** 3.1.1-1+deb8u1 0
1000 http://security.debian.org/ jessie/updates/main amd64 Packages
1000 http://security.debian.org/ stable/updates/main amd64 Packages
100 /var/lib/dpkg/status
3.1.1-1+b2 0
900 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages
900 http://mirrors.kernel.org/debian/ stable/main amd64 Packages
900 http://ftp.us.debian.org/debian/ stable/main amd64 Packages
When I execute sudo apt-get -t jessie-backports install r-base-core, I get:
Reading package lists... Done
Building dependency tree
Reading state information... Done
r-base-core is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 205 not upgraded.
Why doesn't it see the jessie-backportsversion as being newer? How do I debug this? Thanks for any help.
The display shows the *** for the selected variant. Below is the all-important score of a 1000 which is higher than the alternatives of 100 and 500, respectively, for the higher versions.
This is a feature called apt-pinning. You need to adjust the ranking you give the different repos. At equal or lower score, the upgrade to a higher version happens as you would expect.

Resources