zypper install packages from `rpm -qa` output

English Install/Boot/Login
1

Online searches show this has been discussed for at least a decade, but I’ve tried the suggested method without success.

I have a Leap 42.1 system that I’ve been using for years. It has literally thousands of packages which were incrementally installed. I’ve just installed Leap 15.1 on a new machine and to the greatest extent possible want it to have everything the old one does.

As per suggestions, on 42.1 I did:

$ rpm -qa --qf "%{NAME}
" > rpm-qa--qfNAME.txt
$ wc -l rpm-qa--qfNAME.txt
5567 rpm-qa--qfNAME.txt

(The wc is my own addition – like I said, thousands of packages.)

On 15.1 I tried:

fgrep -v gpg-pubkey /tmp/rpm-qa--qfNAME.txt | xargs -- zypper install

Not sure why the “gpg-pubkey” lines need to be removed, but that was suggested so I did it.

Many 42.1 packages are missing from the 15.1 repositories. I expected this. What I want is all the 42.1 packages that exist in 15.1 – I’ll go back into YaST Software Management and add replaced/changed ones as necessary.

Problem is that zypper prints lots of errors and other messages, and then does nothing – it doesn’t install the “good” packages. Examples from the output:

Package 'gimp-help-browser' not found.

'samba-libs' is already installed.

No update candidate for 'make-4.2.1-lp151.7.39.x86_64'. The highest available version is already installed.

`dbus-1-python3' not found in package names. Trying capabilities.

Note that ‘make-4.2.1-lp151.7.39.x86_64’ is not in the .txt file:

$ fgrep make rpm-qa--qfNAME.txt
texlive-makeindex
imake
cmake
makeinfo
make
texlive-makeindex-bin
texlive-makecmds
makedepend
extra-cmake-modules
texlive-makeindex-doc
automake
gccmakedep
texlive-makecmds-doc
libpagemaker-0_0-0

I’ve confirmed that if there are any missing, etc. package in the .txt file zypper won’t install anything. This text file doesn’t install anything:

emacs
python2-numpy
non-existent-package-foobar
python3-numpy
python2-scipy
python3-scipy

But removing the “non-existent-package-foobar” and doing cat file.txt | xargs zypper installworks and installs emacs, numpy, scipy, and all their dependencies.

Adding the global “–non-interactive” flag to zypper doesn’t help. And I don’t want to use “–force”. I specifically don’t want to overwrite existing/installed packages from the 15.1 base install with other ones.

Am I doing anything wrong in my zypper command? Is this at all possible? I really don’t want to have to install thousands of packages interactively with YaST Software Management. Or edit the 5000 line “rpm-qa–qfNAME.txt” file removing hundreds of problematic lines. Thanks for any suggestions.

2

How about something like this? With a list of package names in package.list, create a script eg install.sh…

IFS=$'
'

for package in `cat package.list`; do
    zypper --non-interactive install $package
done
3

In the dark ages before Tumbleweed I refrained from automatically installing thousands of packages. Instead I started with a functional basic installation including all patterns I presumably needed. Only then I installed missing applications. zypper automatically pulls in whatever packages are needed by the application. To my experience you are done after a few steps. When done your installation is free of clutter by obsolete packages. You may consider running zypper instead of YaST sw_single.

4

Yes, thanks. That was one of the alternate approaches I found in web searches.

The advantage (I think?) would be that each failed package wouldn’t keep all the other/good ones from being installed. The disadvantage over the xargs method is that it would be very, very slow – each invocation of zypper starts with a delay of 15-20 seconds in:

Loading repository data...
Reading installed packages...
Resolving package dependencies...

And that’s with just the base system installed. I assume the delay will grow linearly (or exponentially!) with the number of packages. Multiply by 5000+ packages. :frowning: BTW, the web page suggesting this shell loop said it would be slow but didn’t explain why.

I was really hoping for a zypper option, something like “–ignore-failed-packages”, but I can’t find one. If there’s no other way I guess I’ll have to edit the failed packages out of the list. Hopefully all at once, not incrementally one at a time.

5

Thanks. Yes, that’s my fallback position. It’s just that I’m sure I have (and use) many packages that aren’t in the patterns. This is how I ended up where I am on 42.1, hence the rpm -qa list.

I could do 15.1 the same way, incrementally going into YaST (or zypper) each time I hit something I don’t already have. I hate doing it because it interrupts my work flow, and it’s even slower than one would think because I compulsively export YaST’s user-packages.xml each time, and also do a rpm -qa and zypper search -i. Those are in my daily backups, the idea being that if I have a total hardware crash and have to build a new machine (or just disk) I can get right back to where I was.

… except I’m now finding it might not work. (Probably better if recreating openSUSE N.m from the same N.m instead of a different one.) It’s the old Heisenberg uncertainty principle of backups: You never know if they’ll work until you need them. :frowning:

6

Hi
Why not do a search on the packages to create a new list, it will output any it can’t find… there is also verbosity and a debug solver option?

7

Good suggestions. I look into them, thanks. Might yield some more information on why I’m getting errors like: “No update candidate for ‘make-4.2.1-lp151.7.39.x86_64’. The highest available version is already installed.” when I have no explicit version numbers in my text file.

Thing is, I already have the list of errors from the output of the failed zypper install, so if I’m editing the text file I can just remove those and hopefully the rest will work. I’m right now in the middle of manually adding “patterns” with YaST. I figured it couldn’t hurt to have a more-than-minimal base to start from because I’ve already seen that zypper knows if something’s already been installed (hopefully those are just informative messages, not errors that will break the rest as before).