| View previous topic :: View next topic |
| Author |
Message |
authority
n00b
Joined: 18 Dec 2003
Posts: 10
Location: Dallas, Texas
|
 Posted: Wed Oct 18, 2006 7:50 pm Post subject: What's the purpose of the vmware-modules ebuild? |
 |
|
I think the topic says it all, but what is the purpose of the vmware-modules ebuild?
My first disagreement with the vmware-modules came when the modules were updated to 1.0.0.15, which I come from VMWare Server 1.0.1, but were incompatible with my VMWare Workstation 5.5.1. Plus I had to download another 100+ megs of the Server tarball, when I already a perfectly fine and fully compatible copy of the modules in the Workstation tarball. It's retarded to have to download a 100+ meg tarball so I can get, what is probably less than 1% of that, the actual modules code.
Follow that up with /opt/vmware/workstation/bin/vmware-config.pl seemingly broken now. Instead of just running that simple script when switching kernels, i have to emerge vmware-modules again. I don't really see the point in breaking the first script just to replace it with another, longer method of achieving the same thing.
Just a little perturbed here, especially since I can't see any improvement and I can't seem to find any documentation on why the change was made.
_________________
--
/* authority */ |
|
| Back to top |
|
 |
Corona688
Veteran
Joined: 10 Jan 2004
Posts: 1204
|
| Posted: Wed Oct 18, 2006 8:12 pm Post subject: |
|
|
suffice to say that vmware, while useful, is one of the most brittle pieces of software I've encountered since leaving Windows. If it works, don't let portage upgrade it, don't let it upgrade itself, don't do ANYTHING to it.
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Thu Oct 19, 2006 5:13 am Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| authority wrote: | | what is the purpose of the vmware-modules ebuild? |
It's the kernel modules that need to be recompiled after booting into a new kernel. E.g., I have my in /etc/conf.d/local.start
| Code: | if ! modprobe vmmon ; then
modprobe -r vmmon
modprobe -r vmnet
echo "Recompiling vmware"
emerge vmware-modules
/etc/init.d/vmware restart
if ! modprobe vmmon ; then
echo "Failed to recompile & restart vmware."
fi
fi |
|
|
| Back to top |
|
|
yabbadabbadont
Advocate
Joined: 14 Mar 2003
Posts: 4791
Location: 2 exits past crazy
|
| Posted: Thu Oct 19, 2006 5:22 am Post subject: |
|
|
Since the modules are common to all the various vmware ebuilds, they were split out into their own to make maintaining them easier.
EDIT: Easier for the ebuild maintainers that is. 
_________________
| Bones McCracker wrote: | | On the other hand, regex is popular with the ladies. |
|
|
| Back to top |
|
|
authority
n00b
Joined: 18 Dec 2003
Posts: 10
Location: Dallas, Texas
|
| Posted: Thu Oct 19, 2006 2:11 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| PaulBredbury wrote: | | authority wrote: | | what is the purpose of the vmware-modules ebuild? |
It's the kernel modules that need to be recompiled after booting into a new kernel. E.g., I have my in /etc/conf.d/local.start
|
That still doesn't explain the need for the vmware-modules ebuild. VMWare included a script to rebuild the modules already.
_________________
--
/* authority */ |
|
| Back to top |
|
|
authority
n00b
Joined: 18 Dec 2003
Posts: 10
Location: Dallas, Texas
|
| Posted: Thu Oct 19, 2006 2:20 pm Post subject: |
|
|
| yabbadabbadont wrote: | Since the modules are common to all the various vmware ebuilds, they were split out into their own to make maintaining them easier.
EDIT: Easier for the ebuild maintainers that is. |
But what is the point of maintaining them separately? 
-- You can't mix and match VMWare and module versions. Upgrade the modules without upgrading the application and it breaks. 
-- If you've got a VMWare product installed, you've already got the modules to go with it. 
-- They weren't really split out because I'm still having to download another 100+ meg tarball of VMWare Server just to get the modules.  (I use VMWare Workstation)
The vmware-modules ebuild, if it must exist, it should at least be smart enough to use the modules for the VMWare product you have installed. 
_________________
--
/* authority */ |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Thu Oct 19, 2006 2:22 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| authority wrote: | | VMWare included a script to rebuild the modules already. |
Well, VMWare included an interactive script to set up vmware. emerge vmware-modules is, happily, not interactive.
It's up to you to choose the right versions of ebuilds. |
|
| Back to top |
|
|
authority
n00b
Joined: 18 Dec 2003
Posts: 10
Location: Dallas, Texas
|
| Posted: Thu Oct 19, 2006 3:59 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| PaulBredbury wrote: | | authority wrote: | | VMWare included a script to rebuild the modules already. |
Well, VMWare included an interactive script to set up vmware. emerge vmware-modules is, happily, not interactive.
It's up to you to choose the right versions of ebuilds. |
I can see the benefit of non-interactive, but seeing as how changing kernels is interactive, rebuilding modules is just a part of that.
And if its up to me to choose my versions of ebuilds, what's the point of automatic dependency checking and resolution?
_________________
--
/* authority */ |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Thu Oct 19, 2006 4:41 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| authority wrote: | | rebuilding modules is just a part of that. |
No, having to answer questions manually in the vmware script which have already been answered is pointless. It's not part of anything, unless that thing is tedious redundancy
I'm not gonna explain the subtleties of a package manager, and its obvious inability to know whether future versions of any package are compatible with any other version of any other package - Googling can do that. Also bear in mind that the dependency resolution is often a compromise, because there isn't an infinite number of monkeys available to do the testing and update the 10,000+ ebuilds. |
|
| Back to top |
|
|
authority
n00b
Joined: 18 Dec 2003
Posts: 10
Location: Dallas, Texas
|
| Posted: Thu Oct 19, 2006 5:28 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| PaulBredbury wrote: | | authority wrote: | | rebuilding modules is just a part of that. |
No, having to answer questions manually in the vmware script which have already been answered is pointless. It's not part of anything, unless that thing is tedious redundancy |
You don't have to answer them every time. I think i hit enter once and it rebuilds with the same settings as before. I bet Gentoo could probably modify the script to even skip that question and automatically rebuild with the defaults. The wmare-modules ebuild is just a bloated method for doing that. Then you could run the VMWare original if you ever wanted to make any changes.
If anything, the vmware-modules ebuild should be optional for those who want the bloated, non-interactive rebuild of their modules. I was perfectly happy with the hit-enter-once way to rebuild modules, especially since it didn't require me to download another 100 megs for my modules and it didn't try to install the wrong versions of modules.
Honestly, is this the best Gentoo can do? I've seen a lot of very cool things come from Gentoo, but this is just complete ass backwards. We break two things to fix one?
_________________
--
/* authority */ |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Thu Oct 19, 2006 5:54 pm Post subject: Re: What's the purpose of the vmware-modules ebuild? |
|
|
| authority wrote: | | Honestly, is this the best Gentoo can do? |
Of course not. Ebuilds, like all programs, are never "finished" - that's what bugzilla, and especially improvements submitted via bugzilla, are for. There are various options:
Improve the ebuilds and submit the improvements to bugzilla
Write your own variation on the ebuilds and use them instead
Don't use ebuilds, if you're happy to go through the interactive vmware script |
|
| Back to top |
|
|
rburcham
Apprentice
Joined: 20 Mar 2003
Posts: 243
|
| Posted: Sun Oct 22, 2006 5:39 am Post subject: |
|
|
Come on, the man has a point. Breaking the modules out achieved nothing but overcomplicating the vmware upgrade process and breaking everyone's installation. Mine included. At 12:35am.
There was *nothing* wrong with running vmware-config.pl: everyone knew how to do it, it was quick and relatively painless, and most of all it was supported by vmware! Now we have yet another Gentoo-specific method for upgrading/managing a bit of commercial software, and joy of joys, I get to toss another package into my /etc/portage/package.mask to prevent portage from upgrading that package beyond my licensed version.
The thing I like best is how the vmware-config.pl installed by the original vmware-workstation ebuild has been stripped/changed to not even build the modules any longer, with no note provided when you run it regarding the new arrangement or what to do.
I love portage. I love ebuilds. I love Gentoo. All three are designed to facilitate package management and maintenance - you know, make things easier, save time. I just experienced the complete antithesis of that.
Bitching complete.
Sorry, I guess it wasn't complete: This thing where the vmware-modules and vmware-workstation ebuilds have divergent/unrelated version numbering? ABSOLUTE GENIUS. Makes package masking and the associated half-hour long game of "Emerge Russian Roulette" a total blast. Yet oddly satisfying when you hit the right versions :) |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Sun Oct 22, 2006 6:12 am Post subject: |
|
|
| rburcham wrote: | | There was *nothing* wrong with running vmware-config.pl |
It's needlessly interactive. emerge vmware-modules fulfils the necessary step of recompiling the kernel modules after changing the kernel, without the annoyance of being interactive.
There's a big point to be made here, and that is: There's nothing stopping you from using the old method that you're comfortable with. You chose to upgrade. You chose to install vmware-modules. And then, decided that you didn't like it - which is fine. You can always go back to the old method if you like. You have the choice. You can also create variations on the ebuilds. Or write your own scripts, even.
| Quote: | | I get to toss another package into my /etc/portage/package.mask |
The advantage to ebuilds is that they require familiarity with just one package manager and "installation method".
| Quote: | | I just experienced the complete antithesis of that. |
Suggest improvements |
|
| Back to top |
|
|
rburcham
Apprentice
Joined: 20 Mar 2003
Posts: 243
|
| Posted: Sun Oct 22, 2006 2:05 pm Post subject: |
|
|
| Code: | | It's needlessly interactive. |
Yeah but not really though. Point to the bugs.gentoo.org thread where the masses are clamoring over how needlessly interactive vmware-config.pl is. There is no reason to dance around the fact that the package management change in question was undertaken to bring vmware variants more in line with the "module management" posture recently adopted within portage. By and large I am a supporter of this new approach to managing packages that have kernel impact.
| Quote: | | emerge vmware-modules fulfils the necessary step of recompiling the kernel modules after changing the kernel, without the annoyance of being interactive. |
While it may fulfil this necessary step now, it does so only after breaking everyone's vmware with little or no direction on what to do to resolve it. vmware-config.pl fulfilled this step too by the way - in a manner that was well understood and was supported by the company that makes the software. Incidentally, I have searched the forums, and the only posts I have found that associate the word annoyance with vmware-config.pl are yours.
| Quote: | | There's a big point to be made here, and that is: There's nothing stopping you from using the old method that you're comfortable with. |
In point of fact this is not correct, and indeed it is the reason this thread exists. Consider that we all had vmware-workstation installed, and none of the broken-out complimentary packages. The vmware-config.pl now provided by the installed package is deficient - it does not even try to rebuild the modules. It merely allows for the management of virtual network devices. Yet upon updating we all need new modules... this sinking in yet?
| Quote: | | You chose to upgrade. |
Well, kind of, portage told me to. Okay I'll concede this one...
| Quote: | | You chose to install vmware-modules. |
Nope! Had to - big difference. After sleuthing out that it existed by finding this thread, where other folks have complained of the same problem, and THEN determining the correct version through extended trial and error. Other than that you are spot on.
| Code: | | And then, decided that you didn't like it - which is fine. You can always go back to the old method if you like. You have the choice. You can also create variations on the ebuilds. Or write your own scripts, even. |
Well, in my own defense I decided I didn't like it because it didn't work. vmware was broken, would not start, and the de facto way to rebuild the modules was gone and upon running it there were no pointers to any new method. In a completely rational turn of events I decided I didn't like it. What's more I cannot go back to the old method for reasons described above. And while becoming a package maintainer for vmware does have a certain romatic appeal (I hear they get all the chicks) I kind of have my hands full right now.
| Quote: | | The advantage to ebuilds is that they require familiarity with just one package manager and "installation method". |
Well while I may agree on the surface I might respectfully point out that one disadvantage is that users occasionally are subject to poorly implemented unilateral changes. But you don't have to sell me on portage, I love it! Any great tool can be misused though.
| Quote: | | Suggest improvements :wink: |
Sim sala bim:
1. Synchronize the package versions so people who may be licensed-challenged don't have to play 3-card-monty to install the right modules, and subsequently rant in gentoo forums. Seriously, how in the name of Oprah am I supposed to get that 1.0.0.11 fits with 4.5.3.19414-r7? And why 1.0.0.x anyway? Couldn't we have tacked on a few more 0.0.0s? I mean that's just obvious right?
2. Actually make it so people *can* maintain their vmware "the old way."
The xorg package maintainers federated xorg-x11. The kde package maintainers federated kde. I know there are MANY threads where folks had problems and needed support after these changes, but you must admit that the changes were communicated much better, with copius explanation in the ebuilds themselves and general notifications at runtime too. And those packages are monsters. Vmware is tiny by comparison, yet I have spent much more time trying to get it straightened out than the other two combined. |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Sun Oct 22, 2006 2:58 pm Post subject: |
|
|
| rburcham wrote: | | only after breaking everyone's vmware with little or no direction on what to do to resolve it. |
I upgraded with very little pain, without any inside knowledge. An elog or two in the ebuild would help, yes? So file a bug on bugzilla with a 2-line patch to the ebuild, if you wanna help.
| Quote: | | users occasionally are subject to poorly implemented unilateral changes. |
Yeah. A Gentooer needs to know the recovery options, e.g. reverting back to the old ebuild (possibly having to refer to the ebuild archive).
| Quote: | | Seriously, how in the name of Oprah am I supposed to get that 1.0.0.11 fits with 4.5.3.19414-r7? |
Good question. The version numbering looks arbitrary, because it cannot fit with vmware's "versioning". I.e.:
| Code: | cd /usr/portage/app-emulation/vmware-modules
grep VER *
vmware-modules-1.0.0.11.ebuild:VMWARE_VER="VME_V452"
vmware-modules-1.0.0.11-r1.ebuild:VMWARE_VER="VME_V452"
vmware-modules-1.0.0.13.ebuild:VMWARE_VER="VME_V55"
vmware-modules-1.0.0.13-r1.ebuild:VMWARE_VER="VME_V55"
vmware-modules-1.0.0.15.ebuild:VMWARE_VER="VME_S1B1"
vmware-modules-1.0.0.15-r1.ebuild:VMWARE_VER="VME_S1B1"
vmware-modules-1.0.0.8.ebuild:VMWARE_VER="VME_V321" |
| Quote: | | Actually make it so people *can* maintain their vmware "the old way." |
This method always exists. Put the ebuild from my link above into your local overlay. That's what I would have done, if I'd had any tedious difficulty. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
