![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 31/08/2020 21.10, David C. Rankin wrote:
On 8/31/20 4:45 AM, Benjamin Zeller wrote:
I'd guess thats working by using the modalias feature of zypper.
The virtualbox-guest-x11 does have 'namespace:modalias(pci:v000080EEd0000BEEFsv*sd*bc*sc*i*)' in its supplements. Which is used by zypper to figure out the required drivers that should be installed. If that device is available on the system zypper will try to install the driver.
Locking the package would be the proper way to handle this.
That's what I did,
I just added a lock for the virtualbox-guest-x11 package and was then able to update without it attempting to install.
I'm not sure having zypper look at decide it wants to install extra packages in this type situation is a good thing. If somebody installs virtualbox from openSUSE, then that packages is added as a dependency to begin with.
However, if the user has installed virtualbox from another source, then this package should be no more than a "recommends", not something that will evade the --no-recommends option requiring a full lock to prevent the thing -- that was not asked for to begin with -- from installing.
Seems we may have the "cart-before-the-horse" with this logic.
I wouldn't make much of it. The default situation is installing the virtualbox rpm from openSUSE and the additions. Goes fine for most people. If you don't want them, lock them. I do that with many packages, it is fine with me. Years ago zypper and yast had a feature: if you removed a package, it stayed removed. The system remembered your manual action and respected it. But the feature was removed because it had issues, I don't remember which. Since then, you have to remove and lock. A bit of a nuisance, but not much. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)