[opensuse] 15.2 zypper up NEW package virtualbox-guest-x11 - Why? I don't want it... I build guest modules
All, For my 15.2 guests, I use Oracles virtualbox (currently testbuilds) I build my own modules for guest additions. I explicitly removed virtualbox-guest-x11 because I don't want the conflicting guest modules. DKMS rebuilds the modules just fine on kernel update with the vboxadd.service enabled. Now, for some reason, when I attempt zypper up I get: The following NEW package is going to be installed: virtualbox-guest-x11 I know I can just put a lock or exclusion of some type on it -- but why is it trying to install itself as a new package? I didn't ask it to? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
All,
For my 15.2 guests, I use Oracles virtualbox (currently testbuilds) I build my own modules for guest additions. I explicitly removed virtualbox-guest-x11 because I don't want the conflicting guest modules. DKMS rebuilds the modules just fine on kernel update with the vboxadd.service enabled.
Now, for some reason, when I attempt zypper up I get:
The following NEW package is going to be installed: virtualbox-guest-x11
I know I can just put a lock or exclusion of some type on it -- but why is it trying to install itself as a new package? I didn't ask it to?
Try adding option '--no-recommends' - it sounds like that package is being recommended by another one ? -- Per Jessen, Zürich (15.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/31/20 3:04 AM, Per Jessen wrote:
Try adding option '--no-recommends' - it sounds like that package is being recommended by another one ?
Thanks Per, But in this case I already have --no-recommends set. So this is a weird case where there is some logic that sees openSUSE is running in a vbox guest and says -- here install the precompiled guest modules -- without first checking whether the modules are already installed. It just the way openSUSE does virtualbox. It pre-compiles modules for guest additions. But if the user is running the PUEL (Non OSE) virtualbox from Oracle to provide USB, etc.. they are building their modules from source each time a new kernel is installed with DKMS. In fact, when I had Virtualbox 5.2.44 for the host, the virtualbox-guest-x11 package broke everything requiring the manual removal of that package. (I've since switched to the Virtualbox 6.1.13 (testbuilds) for the Arch host running the 5.8.5 kernel -- so I don't want virtualbox-guest-x11 to break the guests compiled from my testbuild. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. On 8/31/20 11:27 AM, David C. Rankin wrote:
On 8/31/20 3:04 AM, Per Jessen wrote:
Try adding option '--no-recommends' - it sounds like that package is being recommended by another one ?
Thanks Per,
But in this case I already have --no-recommends set. So this is a weird case where there is some logic that sees openSUSE is running in a vbox guest and says -- here install the precompiled guest modules -- without first checking whether the modules are already installed.
It just the way openSUSE does virtualbox. It pre-compiles modules for guest additions. But if the user is running the PUEL (Non OSE) virtualbox from Oracle to provide USB, etc.. they are building their modules from source each time a new kernel is installed with DKMS.
In fact, when I had Virtualbox 5.2.44 for the host, the virtualbox-guest-x11 package broke everything requiring the manual removal of that package. (I've since switched to the Virtualbox 6.1.13 (testbuilds) for the Arch host running the 5.8.5 kernel -- so I don't want virtualbox-guest-x11 to break the guests compiled from my testbuild.
-- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
On 8/31/20 10:29 PM, Carlos E. R. wrote:
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.
AFAIK one of the issues was that people forgot they removed the package manually and filed bugs about packages not being installed anymore. But I was not around at the time when that feature was removed so there might have been more issues with that. -- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/09/2020 08.42, Benjamin Zeller wrote:
On 8/31/20 10:29 PM, Carlos E. R. wrote:
On 31/08/2020 21.10, David C. Rankin wrote:
On 8/31/20 4:45 AM, Benjamin Zeller wrote:
...
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.
AFAIK one of the issues was that people forgot they removed the package manually and filed bugs about packages not being installed anymore. But I was not around at the time when that feature was removed so there might have been more issues with that.
Might be, I have forgotten :-) If it was that, YaST could have added an information screen: "not installing such because you removed them manually in the past (or such date)" I remember it was said that the solution was complicated, and left for some other time... which did not come (or I'm confused). So the best compromise was removing the feature :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
David C. Rankin wrote:
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.
It is difficult to imagine how zypper should/could deal with that. Change a package dependency due to what a user may or may not have done ? -- Per Jessen, Zürich (16.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 9/1/20 3:07 AM, Per Jessen wrote:
David C. Rankin wrote:
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.
It is difficult to imagine how zypper should/could deal with that. Change a package dependency due to what a user may or may not have done ?
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2020 10.23, David C. Rankin wrote:
On 9/1/20 3:07 AM, Per Jessen wrote:
David C. Rankin wrote:
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.
It is difficult to imagine how zypper should/could deal with that. Change a package dependency due to what a user may or may not have done ?
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
No, zypper only reacts to rpms. If you install an rpm in any manner, zypper reacts. Well, there is a manner in which it doesn't, but I'm sure you did not use it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2020 14.19, Patrick Shanahan wrote:
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic.
As long as it is an rpm. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E.R. <robin.listas@gmx.es> [09-01-20 08:24]:
On 01/09/2020 14.19, Patrick Shanahan wrote:
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic.
As long as it is an rpm.
it does need to be in the rpmdb but does not need to actually be an rpm. The data in the rpmdb may be put there by hand, ie: faked, as long as it fits zypper's criteria. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2020 14.30, Patrick Shanahan wrote:
* Carlos E.R. <robin.listas@gmx.es> [09-01-20 08:24]:
On 01/09/2020 14.19, Patrick Shanahan wrote:
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic.
As long as it is an rpm.
it does need to be in the rpmdb but does not need to actually be an rpm. The data in the rpmdb may be put there by hand, ie: faked, as long as it fits zypper's criteria.
I have never seen or heard anyone do this :-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 9/1/20 7:19 AM, Patrick Shanahan wrote:
* David C. Rankin <drankinatty@suddenlinkmail.com> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic.
The problem is this, if you install virtualbox-kmp because you want the modules to automatically be rebuilt on kernel update (regardless where virtualbox comes from), then zypper tries to install virtualbox-guest-x11 Which makes little sense, since virtualbox-kmp will rebuild the guest modules on kernel update negating the need for virtualbox-guest-x11 So zypper should not automatically try and install virtualbox-guest-x11 just because it sees virtualbox-kmp installed. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/09/2020 09.08, David C. Rankin wrote:
On 9/1/20 7:19 AM, Patrick Shanahan wrote:
* David C. Rankin <> [09-01-20 04:26]: [...]
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did.
zypper *only* cares that a package is present/installed, not that zypper installed it or that David installed it using other incantations and mystic.
The problem is this, if you install virtualbox-kmp because you want the modules to automatically be rebuilt on kernel update (regardless where virtualbox comes from), then zypper tries to install
virtualbox-guest-x11
Which makes little sense, since
virtualbox-kmp
will rebuild the guest modules on kernel update negating the need for
virtualbox-guest-x11
So zypper should not automatically try and install virtualbox-guest-x11 just because it sees virtualbox-kmp installed.
zypper does what the packages mandate, within the possibilities. So try bugzilla against virtualbox-kmp -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 9/1/20 3:07 AM, Per Jessen wrote:
David C. Rankin wrote:
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. It is difficult to imagine how zypper should/could deal with that. Change a package dependency due to what a user may or may not have done ?
Precisely why when zypper says "Hey, not my Virtualbox!", it shouldn't have tried to do anything, but that isn't what happened. After finding a virtualbox that wasn't zypper's zypper went ahead a tried to add packages to it anyway -- that is the problem. It shouldn't have, but it did. How would zypper INSIDE the VM know what virtualbox you have installed on the host machine? Zypper does not and should not care about that, all it sees is that
On 9/1/20 10:23 AM, David C. Rankin wrote: there is a device for which it has a driver available and it is installed. -- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 8/31/20 3:04 AM, Per Jessen wrote:
Try adding option '--no-recommends' - it sounds like that package is being recommended by another one ?
Thanks Per,
But in this case I already have --no-recommends set.
Ah. So it is a hard requirement. Yeah, then you're left with locking it.
So this is a weird case where there is some logic that sees openSUSE is running in a vbox guest and says -- here install the precompiled guest modules -- without first checking whether the modules are already installed. It just the way openSUSE does virtualbox. It pre-compiles modules for guest additions. But if the user is running the PUEL (Non OSE) virtualbox from Oracle to provide USB, etc.. they are building their modules from source each time a new kernel is installed with DKMS.
Okay - isn't that often going to be a risk for a clash or even something being overwritten? I install my own ABC module and some package also wants to install the ABC module.
so I don't want virtualbox-guest-x11 to break the guests compiled from my testbuild.
zypper al virtualbox-guest-x11 (I guess). -- Per Jessen, Zürich (17.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Benjamin Zeller -
Carlos E. R. -
Carlos E.R. -
David C. Rankin -
Patrick Shanahan -
Per Jessen