woot. :) Reproducible: Always Steps to Reproduce: 1. 2. 3.
The current ebuild appears to work if you change the NP line to NP="VMware-workstation-e.x.p-11608" and do ebuild /usr/portage/app-emulation/vmware-workstation/vmware-workstation-5.0_beta1.ebuild digest
...not until it goes final.
What is the point in having an ebuild for the beta if it doesn't install the latest version? It's only a matter of changing the version number.
I second Neil Bothwick's comment. Customarily with all other beta software I have seen in portage, whether hardmasked(M+/M~) or or simply testing(~), the ebuilds are updated for each new beta until the software does reach final. And sometimes before the software reaches final it leaves the hardmasked state for testing. Just quickly browsing portage I found this example: zile-1.7_beta3-r1.ebuild. Not only is it beta but it is marked as stable on 3 of 4 architectures. Why not simply make a new ebuild called vmware-workstation-5.0_beta1_r1 or vmware-workstation-5.0_beta2 ? This keeps people from having to rename their files (ie: the new vmware beta to the old filename to make it work, or changing the ebuild themselves). I just don't see any arguments against this sorry.
Why was this beta software unmasked? I can understand it being here, but it should be masked as per http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4 : There is a difference between using package.mask and ~arch for ebuilds. The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. For example, if gimp-1.2.0 is the stable release from Gimp developers, and a new bug fix release is available as 1.2.1, then a developer should mark the ebuild as ~arch for testing in portage because the release is deemed to be stable. In another example, if Gimp decides to release an unstable/development series marked as 1.3.0, then these ebuilds should be put in package.mask because the software itself is of development quality and is not recommended by the developers for distribution.
You're right, it shouldn't be unmasked on x86. OTOH, I think it's perfectly appropriate that it not be masked on amd64, as 4.5.x isn't exactly "stable" either.
*I* will NOT add a VMWare beta of any kind into portage. I already get more VMWare bugs than I can fix, and I refuse to put in a piece of commercial closed-source software into portage that the upstream authors do not consider stable enough for a final release.
GRRR... OK, boys.... WHY DID YOU ADD THIS PACKAGE TO PORTAGE? Jason, I think you just volunteered as the new maintainer. *grin*
@Neil: sync your tree, this was updated 2 days ago @Curtis: read package.mask @Chris: I really don't think anyone is asking you to fix bugs in a beta version of the software. I would mark all beta bugs UPSTREAM or WONTFIX.
Mike: I have synced, I do it every day. I posted my comment three days ago, before the ebuild was updated. Chris: The VMWare beta was already in portage, but only usable by the few on the closed beta program. The only request is that this ebuild is now version-bumped to handle the later, public, beta.
