Spec URL: http://members.iinet.net.au/~timmsy/vmware-requirements/vmware-requirements.spec SRPM URL: http://members.iinet.net.au/~timmsy/vmware-requirements/vmware-requirements-1.0-1.fc9.src.rpm Description: Use this package to install the packages required to run vmware locally. This package does not include the free vmware-server or vmware-server-console package itself. They can be obtained from the vmware website. rpmlint is not clean: vmware-requirements.src:45: E: hardcoded-library-path in /usr/lib/libgdk-x11-2.0.so.0 vmware-requirements.src:47: E: hardcoded-library-path in /usr/lib/libX11.so.6 vmware-requirements.src:49: E: hardcoded-library-path in /usr/lib/libXtst.so.6 vmware-requirements.src:51: E: hardcoded-library-path in /usr/lib/libXt.so.6 vmware-requirements.i386: W: no-documentation vmware-requirements.i386: E: no-binary vmware-requirements-server.i386: W: no-documentation vmware-requirements-server.i386: E: devel-dependency kernel-devel vmware-requirements-server-console.i386: W: no-documentation 4 packages and 0 specfiles checked; 6 errors, 3 warnings. Notes: 1. Is there a way in an x86_64 .spec require an eg gtk2.i386 package, without resorting to named file path Requires ? 2. I can make some small readme files to satisfy the no-documentation warnings 3. No binary is correct. The top level package pulls in the 2x sub packages, for the case where you want to run the vmware-server-console on the same machine as the vmware-server. 4. This does not require the VMware's non-open source vmware-server rpms. It only provides an easy way to get prerequisite packages installed so that vmware-server package can run, which saves a lot of messing around. 5. Is it worth changing the name to vmware-prerequisites: $ su -c 'yum install vmware-prerequisites' might be clearer ?
Koji scratch build result (success): http://koji.fedoraproject.org/koji/taskinfo?taskID=1022934
Vmware should supply this, not Fedora.
Agreed, but I think they never will.
(In reply to comment #3) why you don't fire your efforts in direction of open source programs, like KVM, xen or QEMU ? vmware is not opensource and your contribution can't be accepted. please take a look. https://fedoraproject.org/wiki/ForbiddenItems#VMware I am also agree with Jason Tibbitts "Vmware should supply this, not Fedora."
(In reply to comment #4) > why you don't fire your efforts in direction of open source programs, like KVM, > xen or QEMU ? USing Fedora gives users like me the advantages of Fedora and the capability to contribute to the Fedora Project, but virtualization gives me what they may require for the machine to be a useful (winxp) in the real employment world. > vmware is not opensource Correct. > and your contribution can't be accepted. I believe this to be incorrect. Please point to the section of the guidelines that would exclude this meta package. > please take a look. I have. Did you notice that this request for review is a meta-package only. It does not require any non-open source packages, nor any packages outside of the Fedora world. At all. I understand that there will be many who don't support the out of Fedora applications, that this this will make easier to use, but I am yet to see anything that would stop this package actually being acceptable to Fedora, and am hence re-opening.
(In reply to comment #5) > USing Fedora gives users like me the advantages of Fedora and the capability to > contribute to the Fedora Project, but virtualization gives me what they may > require for the machine to be a useful (winxp) in the real employment world. I am using kvm to virtualize window$ at the ratio of 20:1, with extreme performance. in real employment world we use xen/kvm/qemu, have you tried one of these ? If you want to leave this ticket open then go ahead, I am curious to see what other developers think about this.
I agree, we shouldn't include support metapackages for proprietary software in Fedora. If you want to do something for virtualization in Fedora, there's plenty of work to do e.g. with VirtualBox which is GPL.
There are several issues here: It's a metapackage. We don't really want those in the distro. Yes, there are existing examples, but that doesn't make them good examples. The proper solution for this kind of thing would be to use a comps group instead. Of course, I'm sure that if you did commit a comps group for this, a line would form to revert it. Are there plans to do this for whatever other commercial software someone might install? Why not have -requirements metapackages for every other piece of software that nobody can bother to properly package for the distribution? We didn't even do this for flash (after having a similar discussion, mind you). Why would we do it for vmware? Honestly, it is the responsibility of the software vendor to do integration like this. I'm sure there are many in the community who would be willing to assist them in setting up a proper repository for Fedora users, with real packages that have proper dependencies. This half-way solution just doesn't do the job on many levels, and entangles the distribution with semi-official support for some random vendor's software. No, thanks.
(In reply to comment #8) > existing examples, but that doesn't make them good examples. The proper > solution for this kind of thing would be to use a comps group instead. Is it possible in the comps group definition to require 32 bit libraries when installing / running a 64bit kernel system ? (there is no evidence of such in the eg Fedora-10-comps.xml). Are comps groups made visible outside of during the anaconda installation (eg like pup used to) ?
Is it not an option to create an installation instructions document on the wiki, or propose for the VMware website, that states the packages you need to install on x86_64 / i386 before installing VMware (server)?
I use VMWare a lot but I do have a hard time seeing this making it into Fedora even if brought to FeSCO. David I think it would be more productive to package this for RpmFusion. > in real employment world we use xen/kvm/qemu No offense, but you don't know what you're talking about. VMWare's share of the virtualization market is about 80%. The rest is Microsoft. The FOSS solutions are in the noise (unfortunately).
(In reply to comment #10) > Is it not an option to create an installation instructions document on the > wiki, Well there is enough 3-4 page documents. The point with packaging is to make it perhaps as easy as: 1. yum install vmware-requirements 2. yum -C localinstall /downloads/vmware-server*1.0.8.rpm 3. vmware-config.pl > or propose for the VMware website, that states the packages you need to > install on x86_64 / i386 before installing VMware (server)? Sure it would be great if vmware: - packaged the two free to use apps specifically for fedora (an os that they do not support - at all) - at least open sourced / GPLd the vmware-server-console app so that it can be included in distributions. (In reply to comment #11) > I use VMWare a lot but I do have a hard time seeing this making it into Fedora > even if brought to FeSCO. David Well, some individuals have rejected having this helper package on a few grounds, none of whom are able to reference a part of the "Packaging Guidelines" that it runs foul of. The other suggestion of using comps groups has the issue that it can not work in this case on x86_64. Also, there is major changes beginning development that would make comps groups essentially go away, to be replaced with on-the-fly-built metapackages that achieve mostly the same goals. see: http://www.redhat.com/archives/fedora-packaging/2009-January/msg00021.html http://www.redhat.com/archives/fedora-packaging/2009-January/msg00032.html http://thread.gmane.org/gmane.linux.redhat.fedora.devel/102644 I was reminded that the Fedora Community make Fedora a possibility. Do we want this package in Fedora ? Let me suggest that to force the resolution of the issue, perhaps it is simplest for a sponsored reviewer to review the package. If no packaging problems are found, accept the package. Once either cvs or builds are requested, this might cause some opened eyes and lead to a FeSCO discussion / decision, if anyone cares enough to reject it... > I think it would be more productive to package this for RpmFusion That is the last resort, and we need to confirm that there is no possibility of the package being accepted into Fedora proper first, with an actual reason why not. (That is the first question that an RPM Fusion reviewer would ask - why can't it be in Fedora ?). ----- Updated Spec URL: http://members.iinet.net.au/~timmsy/vmware-requirements/vmware-requirements.spec SRPM URL: http://members.iinet.net.au/~timmsy/vmware-requirements/vmware-requirements-1.0-2.fc10.src.rpm - add missing server requires of files from pam.i386
(In reply to comment #12) > Let me suggest that to force the resolution of the > issue, perhaps it is simplest for a sponsored reviewer to review the package. > If no packaging problems are found, accept the package. Once either cvs or > builds are requested, this might cause some opened eyes and lead to a FeSCO > discussion / decision, if anyone cares enough to reject it... "Just do it and see if anyone complains"? That seems a bit off. I'll raise this to FESCo and/or the Packaging committee, we'll get it sorted.
(In reply to comment #13) > "Just do it and see if anyone complains"? That seems a bit off. Perhaps I could have written more clearly, "if a reviewer helps to make sure that there is no non-conforming parts of the spec, then at least a committee decision wouldn't be made confused by such issues." > I'll raise this to FESCo and/or the Packaging committee, we'll get it sorted. Excellent, thanks Bill. I also see that someone blocked on FELegal, but I'm not sure what issue they are concerned about.
> I also see that someone blocked on FELegal, but I'm not sure what issue they > are concerned about. vmware is a registered trademark, we need authorization to use this name ?
Itamar, please remove the legal block.
FESCo has voted not to allow crutches for 3rd party packages, such as this one, into Fedora. This package is therefore blocked from Fedora.
OK, thanks Jon for updating the review request, and to FESCo in taking some time to examine the issue involved. Looking forward to how this went down in the irc log/meeting notes ;).
For future reference for similar non Fedora application support packages, please see the FESCo IRC log at: https://fedoraproject.org/wiki/Meeting:Fesco_IRC_Log_20090130#tJan_30_11:46:53 and summary: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/104241