Weird dependency satisfaction in open-vm-dkms with JeOS style (linux-virtual) kernel installed
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| open-vm-tools (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
| Lucid |
Won't Fix
|
Low
|
Unassigned | ||
Bug Description
Binary package hint: open-vm-dkms
Ubuntu 10.04 alpha 2 (i386 / Server) media
"Minimal Virtual Machine" (i.e., Ubuntu Server JeOS) installation
"OEM Mode" enabled and still active
All repository classes enabled (main, etc...)
Updates current through mid-day 2010-01-19 (apt-get upgrade & apt-get dist-upgrade)
While doing some routine testing, I happened across a strange fulfillment of dependencies in open-vm-dkms which resulted in in a failure to build the required kernel modules as the required header package doesn't get installed.
If you perform the following:
sudo apt-get --no-install-
you will be forced to include the kernel headers for the _RT_ kernel subtype, and not the _Virtual_ subtype actually being used -- the linux-virtual meta-type maps to linux-2.
I did note that the more generic "linux-headers" meta-package is listed as recommended according to apt-get, but the "--no-install-
Expected behavior would have been to either force the meta-package for the subtype in-use (linux-virtual -> linux-headers-
apt-cache showpkg open-vm-dkms
confirms that this is a reasonable expectation.
Manually fulfilling the dependency via
sudo apt-get --no-install-
results in a successful installation and build of the required kernel modules.
open-vm-dkms 2009.11.
| Clint Byrum (clint-fewbar) wrote | #1 |
| Changed in open-vm-tools (Ubuntu): | |
| status: | New → Fix Released |
| importance: | Undecided → Low |
| Changed in open-vm-tools (Ubuntu Lucid): | |
| status: | New → Won't Fix |
| importance: | Undecided → Low |
| tags: | added: jeos lucid |
Hi! Thanks for taking the time to file a bug report and help us make Ubuntu better!
Indeed, this does seem to happen on lucid.
On maverick, natty, and oneiric, the same command only pulls in dkms, the headers are not in the dependency chain. This results in an entirely different failure, but one that seems to be by design of the dkms system.
The work around of course, is to install the virtual headers first. In depends: the maintainer may have good reason to default to the generic 'linux-headers' instead of 'linux-
Marking Fix Released since Oneiric does not display the behavior. Opening task against lucid, importance low. I don't think this is actually SRU worthy, as the workaround for many will be, I think, quite obvious, which is, to install the linux-headers-