there doesnt seem to be any need for the blockers in the vmware packages: ~app-emulation/vmware-modules-1.0.0.15 !<app-emulation/vmware-modules-1.0.0.15 !>=app-emulation/vmware-modules-1.0.0.16 you already have a force RDEPEND on 1.0.0.15 already, so no need for the blockers
We'd seen some issues in the past where portage suggested the upgrade even with the ~vmware-modules-1.0.0.##, so Chris added in the blockers. They oughtn't make upgrading painful, and it should stop people manually upgrading because they think they're out of date, and then filing bug reporting when it doesn't work (which we've had happen). I believe the only extra burden on users is to uninstall the pervious product when they go to put a new one in place. Are there any other negative effects besides this?
that smells like a portage bug that should have been fixed but wasnt imo, this negative effect is significant ... world updates should be smooth, not require micro management every step of the way
plus, since you need to run `/etc/init.d/vmware start` in order to use vmware, cant you just put a runtime check there ?
The vmware init scripts are generally simple wrappers, and verifying the compiled module version and then determining which product we're about to run isn't likely to be as trivial as adding dependency checks. Also do people change vmware products often enough to run into this as a problem very often? I expect any issues encountered because of this to be quite rare. I'd be very happy to see the block dependencies go, I'm just wary about doing so , and I've got higher priority problems to deal with first (like getting the modules to work with 2.6.22). You'd do best to check with Chris as to whether this is a portage bug or not...
The "portage bug" is from people that "emerge vmware-modules" which causes vmware-modules to be listed in world. Without the blockers, portage will try to "upgrade" the vmware-modules to the "best version" which is what caused the bug in the first place. Also, I've not seen an issue with upgrades myself. Exactly what were you doing that caused the problem? If you were switching products, then it's expected that you would have to remove both pieces of the old product. Anyway, the blockers keep portage from trying to upgrade when users don't use --oneshot on vmware-modules after they've upgraded their kernels. Rather than try to educate every single user who does this every time, we chose to use a technical "solution" to keep them from being able to dork up their systems. Unless you've got a better solution to this, I'd rather keep it as is now.
you're saying that it's expected that you'd have to do: emerge -C vmware-modules emerge vmware-workstation in order to upgrade from vmware-workstation-5.x to 6.x upgrading from 5.x to 6.x actually isnt a big deal from what i can tell ... if you have a 5.x license, you can use 6.x just fine as you can select the vmware capabilities on a per-vm basis. in other words, you can run 6.x with a 5.x license if you set your vm capabilities to the "Workstation 5" level
(In reply to comment #6) > you're saying that it's expected that you'd have to do: > emerge -C vmware-modules > emerge vmware-workstation > in order to upgrade from vmware-workstation-5.x to 6.x No, that should be seamless. If you were switching from workstation to server, then yes, I would expect it. You're saying you had a problem with it upgrading from 5.x to 6.x? If so, which version of portage, because it *used* to work just fine.
you cant see the color output, but ive made sure vmware-modules is not in world but vmware-workstation is root@vapier-m 0 ~ # emerge --version Portage 2.1.3_rc9 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.22.1 i686) root@vapier-m 0 ~ # emerge =vmware-workstation-6* -pq [ebuild N ] dev-cpp/libsexymm-0.1.9 [ebuild N ] x11-libs/libview-0.5.6-r1 [ebuild U ] app-emulation/vmware-modules-1.0.0.16 [1.0.0.15-r1] [ebuild FU ] app-emulation/vmware-workstation-6.0.0.45731 [5.5.4.44386] [blocks B ] >=app-emulation/vmware-modules-1.0.0.16 (is blocking app-emulation/vmware-workstation-5.5.4.44386) [blocks B ] <app-emulation/vmware-modules-1.0.0.16 (is blocking app-emulation/vmware-workstation-6.0.0.45731)
This is a again a problem now, as the stable vmware-modules (1.0.0.5-r1) does not compile with the stable gentoo-sources-2.6.27-r7 (see bug #242098), while 1.0.0.23 compiles and works fine. Please remove the blocks (which now screw up every world update) or stablize vmware-modules-1.0.0.23.
Sven, stabilizing the 1.0.0.23 modules won't help you, because if you're using a product that requires vmware-modules-1.0.0.15, it requires vmware-modules-1.0.0.15, a later version won't work. You probably want bug 227303, which monitors the problem of 1.0.0.15 not building against 2.6.26 onwards.
Dependencies on vmware-modules are implemented a bit differently now. But it's still true: every version of vmware product requires specific version of modules. Closing bug.
