On my Fedora 19 system, yum update attempts to reinstall a large number packages I have previously removed. This should not happen, as the packages listed are not installed and should not be suggested by yum. How can I make yum work in the expected manner - with updates suggesting only upgrades to preinstalled packages.
Background: I have been trying out new DEs - installing and removing them as I go. Currently, I'm in a DE-less state, booting directly into a tty terminal. My system has no (or a few hidden) xfce or cinnamon packages to "upgrade", yet the package manager is suggesting 300 packages to install, totaling 600M of new install.
Terminal output gist:
https://gist.github.com/Redoubts/29400f0b98cd13120a6a#file-gistfile1-txt
Short answer - It's not possible to disallow installing any packages from the depenency chain. Either you install all of them or drop those who depends on unwanted packages.
In some cases, when the package from a dependency chain is required only during some specific stages of installation (say for execution of a pre- or post-install scripts), it's possible to remove thise package later, after the complete installation. But that's not what you want I suppose.
Related
I am attempting to install closed source software from Silego, GreenPAK Designer, on a machine running Fedora 19. The supported installation packages on Silego's Website only target Ubuntu and Debian. I downloaded the .deb package and used Alien to convert to an RPM. So far so good, but a dry run of yum install showed dependency errors, which I solved by installing the necessary packages with yum:
qt5-qbase
qt5-qbase-gui
qt5-qtdeclarative
qt5-qtlocation
qwt
Now, yum installed the above libraries in /usr/lib/ but the GreenPAK RPM defaults to /usr/local/bin as the output dir. I figured I could run
sudo yum localinstall --nodeps --noscripts greenpak-designer-x.x.x.rpm
and get a successful install but I received conflict errors relating to dirs such as '/', '/usr', '/usr/bin' etc. I worked around this issue with:
rpmrebuild -pe --notest-install --replacefiles --noscripts greenpak-designer.x.x.x.rpm
and removing the offending lines in the script. It allowed me to install rpm but the software is broken because of dependency issues (not surprisingly). From the system log:
Jan 4 16:06:49 pelican gnome-session[1729]: /usr/local/greenpak-designer/bin/GP5: error while loading shared libraries: libicui18n.so.52: cannot open shared object file: No such file or directory
The machine has a /usr/lib/libicui18n.so.50
One thing I did not try is rebuilding my shared object cache with ldconfig, which sometimes solves problems with missing .so links when building from source but I don't see how that would apply in this instance (I'm not trying to link object files to libraries, rather simply trying to drop binaries in default install locations, no?)
Of course, I contacted the vendor and begged for an RPM. The contact was helpful but informed me the software folks are on a well deserved break. I thought I'd continue puttering with this in the meantime while I have time.
Any ideas? It seems the solution to this problem would be helpful when trying to install almost any closed source software targeting Debian on a Fedora box.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
So where do I go from here? I'm guessing that there is a bugfix somewhere in libXss. libXss tries to install i686 arch for all it's dependencies.
I'm using Fedora 24 x86_64
Terminal Output
sudo rpm -ivh atom.x86_64.rpm
error: Failed dependencies:
libXss.so.1 is needed by atom-1.13.0-0.1.x86_64
sudo dnf install libXss.so.1
Error: Transaction check error:
file /usr/share/doc/glibc/NEWS from install of glibc-2.23.1-11.fc24.i686 conflicts with file from package glibc-2.23.1-7.fc24.x86_64
sudo dnf install glibc-2.23.1-11.fc.24.x86_64
Package glibc-2.23.1-11.fc24.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
Secondary/Unimportant Question
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
edit
I gave up and decided to install from the copr repo
sudo dnf copr enable mosquito/atom
sudo dnf install atom
Error: Transaction check error:
file /usr/lib64/libkadm5clnt_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
file /usr/lib64/libkadm5srv_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
What is going on?
Can I bypass installing glibc.i686 as a dependency when I already have the x86_64 version?
Not if you need to install 32-bit software — you'll need the 32-bit libs for that. 64-bit libraries aren't supersets of the 32-bit ones.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
This is a frequent problem. Installing 32-bit versions of packages without updating to the latest versions of the main 64-bit packages is not supported. Upgrade first, then install.
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
This can happen if there's an interrupted upgrade transaction. You should be able to dnf remove glibc-2.23.1-7.fc24.x86_64 safely. If that gives you errors, time to stop and make sure nothing else is wrong. Or, you can really just ignore it — next time a new glibc update comes out, it should replace both.
I gave up and decided to install from the copr repo
The errors you see here are actually the same root problem as trying to install 32-bit packages without updating first. RPMs can share files, as long as they are completely identical. That's true in matched versions of the various kerberos packages, but not true if there's a mismatch, and the dependency information doesn't handle this. So, again upgrade to latest packages before installing new ones.
I'm running Fedora Workstation 22 on my Notebook. After installing it, I've done
dnf upgrade
to update all packages (was around 700 MB) - and checked the Gnome-Software applications for Updates. Gnome Software hasn't offered any updates. But sometimes, I get a notification from Gnome software to restart my Computer and install the Updates.
I found this procedure - Offline updating for libraries and components which are currently running - in the Wiki. But I don't understand how this works. If I install dnf upgrade, didn't this command update all packages to the most current version in the repos? Is Gnome-Software using different repositories, or how does this mechanism work?
I wanted to update my entire system via command-line. How can I do than? I'm a bit confused, because - for example - on Debian I could simply type
apt-get update && apt-get upgrade
to update my entire system. How is this possible in Fedora?
Its pretty much easy to update your fedora 22.
Use this command and it will simply update your fedora 22 with all available packages.
sudo dnf update
and if you are already root, simply use
dnf update
and will update your fedora.
For any other query related to update, write it in comments.
When running the transaction check to install mysql i'm getting:
Processing Conflict: mysql55-5.5.29-1.w6.x86_64 conflicts mysql < 5.5
I guess this means i'm attempting to install a package called mysql55-5.5.29-1.w6.x86_64 on to a system with mysql already installed but somehow there is a conflict?
yum says that mysql isn't installed so it was installed without using the repositories. In that case how does yum know there is confict?
it would be good to better under what 'confict' means.
There are many online yum repo available and all are free opensource contribute. So source packages are compiled with different options in each repo. So when we add 2 or more yum repo at a time, it may happen that 2 or more packages are of same version are selected and we get a conflict error.
In your case you added some repo which is providing mysql 5.5 which is already available with some other name in some other repo or already installed but new mysql package is selected by yum for any other package as dependency. Try removing one of the repo or try installing it as yum install mysql-5.5*
You can try this : yum list | grep mysql. It will list mysql in different packages, then you can make a decision to remove one of them and install mysql again.
I've installed Google Chrome on Hardy via the .deb file and would like to configure apt-get for automatic updates.
[I have another machine running Ubuntu Karmic where this works fine; apt-get knows the package as 'google-chrome'; I'm now using a Dell Mini 10 with Ubuntu 8.04 LTS installed]
As part of the .deb install, two entries have been added to the third- party software sources tab:
http://dl.google.com/linux/deb stable main
http://dl.google.com/linux/deb stable non-free main
However if I check for updates with either of these clicked, I get the following error:
Failed to fetch http://dl.google.com/linux/deb/dists/stable/Release Unable to find expected entry main/binary-lpia/Packages in Meta-index file (malformed Release file?)
There is a thread here which indicates others have had the same problem:
http://www.google.co.uk/support/forum/p/Chrome/thread?tid=097d103f87b49abe&hl=en
This references a further thread:
http://code.google.com/p/chromium/issues/detail?id=38608
which suggests the problem has been fixed.
Despite this I remain unable to get it to work, and none of the suggested workarounds seem to work either.
Ideas ? Thanks.
I think the issue here is that the Ubuntu installaion on your Dell Mini uses LPIA (Low Power Intel Architecture) and the Google Software Repository doesn't provide the "google-chrome" package for this architecture. Hence apt-get is giving you an error. You will have to do the updates manually using the "google-chrome" package for the i386 architecture.
On another note, the following thread provides details about repackaging an i386 package for LPIA. I hope this helps.
http://ubuntuforums.org/showthread.php?t=962835