This command finds and installs newly added recommended packages for packages you have already installed. This provides an easy way to get new language bundles for your software or drivers for newly added hardware.
Curious, i tried it in my Tower’s 20170904 TW snapshot. I am quite amazed by the result:
gooeygirl@linux-Tower:~> **zypper inr**
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 8 NEW packages are going to be installed:
clutter-gtk-lang clutter-lang folks-lang goocanvas-lang libgoocanvas-2_0-9 libgtop-2_0-11 libgtop-lang python3-ndg-httpsclient
8 new packages to install.
Overall download size: 930.7 KiB. Already cached: 0 B. After the operation, additional 4.5 MiB will be used.
Continue? [y/n/...? shows all options] (y):
Retrieving package clutter-gtk-lang-1.8.4-2.1.noarch (1/8), 22.3 KiB ( 1.8 KiB unpacked)
Retrieving: clutter-gtk-lang-1.8.4-2.1.noarch.rpm .........................................................................................................[done]
Retrieving package clutter-lang-1.26.2-2.1.noarch (2/8), 415.1 KiB ( 2.4 MiB unpacked)
Retrieving: clutter-lang-1.26.2-2.1.noarch.rpm ..............................................................................................[done (231.2 KiB/s)]
Retrieving package folks-lang-0.11.4-2.1.noarch (3/8), 169.6 KiB (1020.1 KiB unpacked)
Retrieving: folks-lang-0.11.4-2.1.noarch.rpm ..................................................................................................[done (4.5 KiB/s)]
Retrieving package python3-ndg-httpsclient-0.4.0-2.1.noarch (4/8), 49.5 KiB (181.9 KiB unpacked)
Retrieving: python3-ndg-httpsclient-0.4.0-2.1.noarch.rpm ........................................................................................[done (968 B/s)]
Retrieving package libgoocanvas-2_0-9-2.0.3-1.1.x86_64 (5/8), 108.2 KiB (308.5 KiB unpacked)
Retrieving: libgoocanvas-2_0-9-2.0.3-1.1.x86_64.rpm .........................................................................................[done (143.2 KiB/s)]
Retrieving package libgtop-2_0-11-2.38.0-1.1.x86_64 (6/8), 53.1 KiB (113.4 KiB unpacked)
Retrieving: libgtop-2_0-11-2.38.0-1.1.x86_64.rpm ..........................................................................................................[done]
Retrieving package goocanvas-lang-2.0.3-1.1.noarch (7/8), 46.4 KiB (250.6 KiB unpacked)
Retrieving: goocanvas-lang-2.0.3-1.1.noarch.rpm .................................................................................................[done (977 B/s)]
Retrieving package libgtop-lang-2.38.0-1.1.noarch (8/8), 66.5 KiB (242.0 KiB unpacked)
Retrieving: libgtop-lang-2.38.0-1.1.noarch.rpm ..............................................................................................[done (139.1 KiB/s)]
Checking for file conflicts: ..............................................................................................................................[done]
Warning: Checking for file conflicts requires not installed packages to be downloaded in advance in order to access their file lists. See option '--download-in-advance' in the zypper manual page for details.
The following 8 packages had to be excluded from file conflicts check because they are not yet downloaded:
clutter-gtk-lang clutter-lang folks-lang python3-ndg-httpsclient libgoocanvas-2_0-9 libgtop-2_0-11 goocanvas-lang libgtop-lang
Retrieving package clutter-gtk-lang-1.8.4-2.1.noarch (1/8), 22.3 KiB ( 1.8 KiB unpacked)
(1/8) Installing: clutter-gtk-lang-1.8.4-2.1.noarch ......................................................................................................[error]
Installation of clutter-gtk-lang-1.8.4-2.1.noarch failed:
Error: Subprocess failed. Error: RPM failed: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Inappropriate ioctl for device)
Abort, retry, ignore? [a/r/i] (a):
I can’t get my mind around the practical purpose of this command. It thinks it identifies missing packages, warns me it cannot pre-assess their compatibility, downloads them & tries to install them but then discovers that in fact they are incompatible, necessitating me to abort. So, what’s the point? It seems to have been an entirely useless thing to bother with this command. What am i misunderstanding? Is it, maybe, a command intended for Leap not TW?
I don’t mess around with that particular option. I generally just install the required package and any dependencies that may come with it. I don’t come to the same conclusion that you did though…
Warning: Checking for file conflicts requires not installed packages to be downloaded in advance in order to access their file lists. See option '--download-in-advance' in the zypper manual page for details.
The following 8 packages had to be excluded from file conflicts check because they are not yet downloaded:
clutter-gtk-lang clutter-lang folks-lang python3-ndg-httpsclient libgoocanvas-2_0-9 libgtop-2_0-11 goocanvas-lang libgtop-lang
Retrieving package clutter-gtk-lang-1.8.4-2.1.noarch (1/8), 22.3 KiB ( 1.8 KiB unpacked)
(1/8) Installing: clutter-gtk-lang-1.8.4-2.1.noarch ......................................................................................................[error]
Installation of clutter-gtk-lang-1.8.4-2.1.noarch failed:
Error: Subprocess failed. Error: RPM failed: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Inappropriate ioctl for device)
This just means that zypper needed to download the packages listed in order for the solver to determine if there will be any incompatibilities. Of course, you never followed through…
I do find this message misleading (contradictory) though, as they are downloaded already at the time the message comes…that would be a bug IMHO
The following 8 packages had to be excluded from file conflicts check because they are not yet downloaded:
clutter-gtk-lang clutter-lang folks-lang python3-ndg-httpsclient libgoocanvas-2_0-9 libgtop-2_0-11 goocanvas-lang libgtop-lan
is useful when installing nvidia drivers (TW finally got an official nvidia driver) and you’re not sure what driver you need (G02 G03 or G04)
personally I do not use it as it might pull recommended packages I’ve uninstalled it does it’s job good and it’s a must on some systems
Where have you got this idea from? It tries to install and gets error creating lock file. This is not surprising seeing that you run zypper as non-root user. I would actually expect it to fail earlier though, when it downloads packages, but well, I do not openSUSE at hand to check directory permissions.
Oh? The error msg denotes nothing more significant than non-root privileges? I had no idea that this:
[error]
Installation of clutter-gtk-lang-1.8.4-2.1.noarch failed:
Error: Subprocess failed. Error: RPM failed: error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Inappropriate ioctl for device)
…had such a trivial meaning. Why does the msg not MUCH more explicitly indicate this? For example, here’s what occurs if i try two commonplace zypper commands sans-sudo:
gooeygirl@linux-Tower:~> **zypper refresh**
Root privileges are required for refreshing system repositories.
gooeygirl@linux-Tower:~>
gooeygirl@linux-Tower:~> **zypper in vivaldi-stable**
Root privileges are required for installing or uninstalling packages.
gooeygirl@linux-Tower:~>
The difference is chalk & cheese; not only are there unambiguous explanatory words, but they are additionally coloured red for even more obvious focus on the root-cause. Furthermore, in those two examples the clear feedback of a user-error occurs ONE line later, ie, it is “instant”, whereas in the case i posted about, the first feedback given to the user of an error she made is not until THIRTY NINE lines after the initial command.
Yes, it is true that i carelessly ran “zypper inr” without sudo [because i forgot], but when it responded without the anticipated msg, & seemed to be proceeding, i then assumed [wrongly] that for whatever reason it was happy without sudo [which i agree would have been very strange].
So, yes, i made an error… but zypper’s behaviour did not help me like [IMO] it should, & like would be consistent with its other commands.
The downloading requires no root privileges, but to install obviously does. I agree that message could be a little more explicit, but ultimately it’s a reflection of the failure that occurs when attempting to write to /var/lib/rpm/.rpm.lock due to file permissions…
ls -l /var/lib/rpm/.rpm.lock
-rw-r--r-- 1 root root 0 Oct 30 2015 /var/lib/rpm/.rpm.lock
FWIW, running ‘zypper inr’ as user in openSUSE Leap 42.3 gives the following slightly different message…
There’s a few options for zypper inr that were missed in this thread. sudo zypper inr -D does a “dry run”, -d will download only, --details will show you the detailed installation summary, among other options:
@localhost:~> sudo zypper inr --help
install-new-recommends (inr) [options]
Install newly added packages recommended by already installed packages. This can typically be used to install new language packages or drivers for newly added hardware.
Command options:
-r, --repo <alias|#|URI> Load only the specified repositories.
-D, --dry-run Test the installation, do not actually install.
--details Show the detailed installation summary.
--download Set the download-install mode. Available modes:
only, in-advance, in-heaps, as-needed
-d, --download-only Only download the packages, do not install.
Solver options:
--debug-solver Create a solver test case for debugging.
--force-resolution Force the solver to find a solution (even an
aggressive one) rather than asking.
--no-force-resolution Do not force the solver to find solution, let it
ask.
That’s because the thread wasn’t concerned about the options available. The OP was specifically querying the error messages produced, including the one that comes from running it as user.
hofkirchen:~ # zypper pd -i
Loading repository data...
Reading installed packages...
S | Repository | Internal Name | Name | Version | Arch | Is Base
---+--------------+-----------------------+-----------------------+------------+--------+--------
i+ | repo-non-oss | openSUSE-Addon-NonOss | openSUSE NonOSS Addon | 2014-0 | x86_64 | No
i+ | repo-oss | openSUSE | openSUSE Tumbleweed | 20170913-0 | x86_64 | Yes
hofkirchen:~ # zypper verify
Loading repository data...
Reading installed packages...
Dependencies of all installed packages are satisfied.
hofkirchen:~ # zypper inr
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Nothing to do.
hofkirchen:~ #
Now I tried to install the packages listed on your system:
hofkirchen:~ # zypper in clutter-gtk-lang clutter-lang folks-lang python3-ndg-httpsclient libgoocanvas-2_0-9 libgtop-2_0-11 goocanvas-lang libgtop-lang
Loading repository data...
Reading installed packages...
'clutter-gtk-lang' is already installed.
No update candidate for 'clutter-gtk-lang-1.8.4-2.1.noarch'. The highest available version is already installed.
'clutter-lang' is already installed.
No update candidate for 'clutter-lang-1.26.2-2.1.noarch'. The highest available version is already installed.
'folks-lang' is already installed.
No update candidate for 'folks-lang-0.11.4-2.1.noarch'. The highest available version is already installed.
'libgtop-lang' is already installed.
No update candidate for 'libgtop-lang-2.38.0-1.1.noarch'. The highest available version is already installed.
'libgtop-2_0-11' is already installed.
No update candidate for 'libgtop-2_0-11-2.38.0-1.1.x86_64'. The highest available version is already installed.
'python3-ndg-httpsclient' is already installed.
No update candidate for 'python3-ndg-httpsclient-0.4.0-2.1.noarch'. The highest available version is already installed.
Resolving package dependencies...
The following 2 NEW packages are going to be installed:
goocanvas-lang libgoocanvas-2_0-9
The following recommended package was automatically selected:
goocanvas-lang
2 new packages to install.
Overall download size: 154.6 KiB. Already cached: 0 B. After the operation, additional 559.1 KiB will be used.
Continue? [y/n/...? shows all options] (y):
Retrieving package libgoocanvas-2_0-9-2.0.3-1.1.x86_64 (1/2), 108.2 KiB (308.5 KiB unpacked)
Retrieving: libgoocanvas-2_0-9-2.0.3-1.1.x86_64.rpm .......................................................................................................................................................................................................[done (416.1 KiB/s)]
Retrieving package goocanvas-lang-2.0.3-1.1.noarch (2/2), 46.4 KiB (250.6 KiB unpacked)
Retrieving: goocanvas-lang-2.0.3-1.1.noarch.rpm .........................................................................................................................................................................................................................[done]
Checking for file conflicts: ............................................................................................................................................................................................................................................[done]
(1/2) Installing: libgoocanvas-2_0-9-2.0.3-1.1.x86_64 ...................................................................................................................................................................................................................[done]
(2/2) Installing: goocanvas-lang-2.0.3-1.1.noarch .......................................................................................................................................................................................................................[done]
hofkirchen:~ #
And again:
hofkirchen:~ # zypper verify
Loading repository data...
Reading installed packages...
Dependencies of all installed packages are satisfied.
hofkirchen:~ # zypper inr
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Nothing to do.
hofkirchen:~ #
You may want to clean and refresh your repositories:
hofkirchen:~ # zypper ref -h
refresh (ref) [alias|#|URI] ...
Refresh repositories specified by their alias, number or URI. If none are specified, all enabled repositories will be refreshed.
Command options:
-f, --force Force a complete refresh.
-b, --force-build Force rebuild of the database.
-d, --force-download Force download of raw metadata.
-B, --build-only Only build the database, don't download metadata.
-D, --download-only Only download raw metadata, don't build the database.
-r, --repo <alias|#|URI> Refresh only specified repositories.
-s, --services Refresh also services before refreshing repos.
hofkirchen:~ # zypper ref -f
Forcing raw metadata refresh
Retrieving repository 'Application-Geo' metadata ...............................................................................[done]
Forcing building of repository cache
Building repository 'Application-Geo' cache ....................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'MyRepo' metadata ........................................................................................[done]
Forcing building of repository cache
Building repository 'MyRepo' cache .............................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Adobe Systems Incorporated' metadata ....................................................................[done]
Forcing building of repository cache
Building repository 'Adobe Systems Incorporated' cache .........................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'google-chrome' metadata .................................................................................[done]
Forcing building of repository cache
Building repository 'google-chrome' cache ......................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'jalbum' metadata ........................................................................................[done]
Forcing building of repository cache
Building repository 'jalbum' cache .............................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'packman' metadata .......................................................................................[done]
Forcing building of repository cache
Building repository 'packman' cache ............................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'repo-non-oss' metadata ..................................................................................[done]
Forcing building of repository cache
Building repository 'repo-non-oss' cache .......................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'repo-oss' metadata ......................................................................................[done]
Forcing building of repository cache
Building repository 'repo-oss' cache ...........................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'repo-update' metadata ...................................................................................[done]
Forcing building of repository cache
Building repository 'repo-update' cache ........................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'vivaldi' metadata .......................................................................................[done]
Forcing building of repository cache
Building repository 'vivaldi' cache ............................................................................................[done]
All repositories have been refreshed.
hofkirchen:~ #
That’s true, i did, as i erred. However, for the record now, in response to Karl & thanks btw]:
gooeygirl@linux-Tower:~> **zypper inr**
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Nothing to do.
gooeygirl@linux-Tower:~> **zypper pd -i**
Loading repository data...
Reading installed packages...
S | Repository | Internal Name | Name | Version | Arch | Is Base
---+-----------------------+---------------+---------------------+------------+--------+--------
i+ | Main Repository (OSS) | openSUSE | openSUSE Tumbleweed | 20170913-0 | x86_64 | Yes
gooeygirl@linux-Tower:~> **zypper verify**
Loading repository data...
Reading installed packages...
Problem: nothing provides libgstbase-0.10.so.0()(64bit) needed by opera-2:12.16-1860.x86_64
Solution 1: Following actions will be done:
downgrade of opera-2:12.16-1860.x86_64 to opera-46.0.2597.57-1.1.x86_64
install opera-46.0.2597.57-1.1.x86_64 (with vendor change)
Opera Software ASA --> openSUSE
Solution 2: break opera-2:12.16-1860.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
gooeygirl@linux-Tower:~> zypper ref -f
Root privileges are required for refreshing system repositories.
gooeygirl@linux-Tower:~> **sudo zypper ref -f**
[sudo] password for root:
Forcing raw metadata refresh
Retrieving repository 'My_openSUSE_Repo' metadata .........................................................................................................[done]
Forcing building of repository cache
Building repository 'My_openSUSE_Repo' cache ..............................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Vivaldi' metadata ..................................................................................................................[done]
Forcing building of repository cache
Building repository 'Vivaldi' cache .......................................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Main Repository (NON-OSS)' metadata ................................................................................................[done]
Forcing building of repository cache
Building repository 'Main Repository (NON-OSS)' cache .....................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Main Repository (OSS)' metadata ....................................................................................................[done]
Forcing building of repository cache
Building repository 'Main Repository (OSS)' cache .........................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Main Update Repository' metadata ...................................................................................................[done]
Forcing building of repository cache
Building repository 'Main Update Repository' cache ........................................................................................................[done]
Forcing raw metadata refresh
Retrieving repository 'Packman Repository' metadata ----------------------------------------------------------------------------------------------------------/]Retrieving repository 'Packman Repository' metadata .......................................................................................................[done]
Forcing building of repository cache
Building repository 'Packman Repository' cache ............................................................................................................[done]
All repositories have been refreshed.
gooeygirl@linux-Tower:~>
gooeygirl@linux-Tower:~> **zypper verify**
Loading repository data...
Reading installed packages...
Problem: nothing provides libgstbase-0.10.so.0()(64bit) needed by opera-2:12.16-1860.x86_64
Solution 1: Following actions will be done:
downgrade of opera-2:12.16-1860.x86_64 to opera-46.0.2597.57-1.1.x86_64
install opera-46.0.2597.57-1.1.x86_64 (with vendor change)
Opera Software ASA --> openSUSE
Solution 2: break opera-2:12.16-1860.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
gooeygirl@linux-Tower:~> **zypper inr**
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Nothing to do.
gooeygirl@linux-Tower:~>
Notes:
I’m not worried about the Opera dependency issue; that’s long known to me. I keep Opera Presto v12.16 installed "for old time’s sake
", not for serious usage anymore, in fond remembrance of its once mighty stature. My daily browser nowadays since early 2015 is its worthy successor, Vivaldi. 1. Despite now knowing that i need to run "zypper inr
" as root, i deliberately this time still only did it as user, as i wanted to compare the output today to Karl’s, who apparently also only ran as user. 1. I suspect today’s “clean” outcome, vs the original “bad” outcome, might be caused by the fact that i stopped doing daily zypper dup’s
many weeks ago * & now only do it on Saturdays [ie, yesterday afternoon]. Conversely when i did it originally prior to creating this thread, there were already several new snapshots available since my version back then. When i dup’d* yesterday i noticed that many of those named packages featured.
I think you found a bug I tested it on LEAP
an ordinary user can run
zypper inr
and packages will be downloaded but not installed
this should not happen but how important is it I’m not sure
for example if a user tried to install a package
zypper in some_package
he/she’d get a warning/error that they’re not root
he/she’d get a warning/error that they’re not root
Well yes, exactly, as i demonstrated above. Whether this is strictly speaking a bug or not, i’m unqualified to say. However i will happily say that, from a humble amateur user’s perspective, it seems to be poor design of this specific zypper module… IMO, any function that needs root permissions for ANY part of its operations, should error-out with a CLEAR msg, at the beginning of the process, not 39 lines later.
