Bug 1358108
| Summary: | [ESXi][RHEL7.3]open-vm-tools requires perl but spec missing it in Requires section | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Pushpendra Chavan <pchavan> |
| Component: | open-vm-tools | Assignee: | Cathy Avery <cavery> |
| Status: | CLOSED WONTFIX | QA Contact: | ldu <ldu> |
| Severity: | medium | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 7.2 | CC: | aburch, ailan, bishop, boyang, cavery, cww, ikke, jjarvis, joniknsk, jsavanyo, kwalker, ldu, leiwang, mkalinin, mrezanin, pasik, ravindrakumar, ribarry, rjones, sreber, vmware-gos-qa, yacao, ybhasin |
| Target Milestone: | rc | Keywords: | TestOnly |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-03 20:31:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1401400, 1594286 | ||
|
Description
Pushpendra Chavan
2016-07-20 05:27:55 UTC
Seems like a legitimate request. Ravindra: Is it OK to add the Perl dependency? If we add a hard 'Requires: perl' on the base package, that will mean open-vm-tools will be much harder to include in minimal Fedora & RHEL installs (since they tend to dislike including Perl). The only way to work around that is to move deploypkg to a separate subpackage. (In reply to Richard W.M. Jones from comment #2) > Seems like a legitimate request. > > Ravindra: Is it OK to add the Perl dependency? Rich, I will discuss this within our group and get back. Is documenting this in your knowledge base or release notes an option here? (In reply to Ravindra Kumar from comment #3) > > Rich, I will discuss this within our group and get back. Is documenting this > in your knowledge base or release notes an option here? I can create a KCS base _for quick remedy_ but fixing this problem out will be the requested solution. I will attach the published KCS to this bz shortly. Adding this into Actual Documentation will take time, because that follows the same BZ workflow. - Pushpendra See this. Why are some of the VMware Guest OS Customizations not working even after installing open-vm-tools ? https://access.redhat.com/solutions/2456451 This is still in unverified state. Once I get confirmation from VMWare as well that it's really required, we can mark it Verified. Again, the fix will be better, or an official statement from both Vendors on this. Thanks, Pushpendra Thanks Pushpendra. This needs to be documented. Please document it for now and we will work on removing the dependency in future. *** Bug 1420620 has been marked as a duplicate of this bug. *** This issues is related to Bug 1418930 which is a request to increase package granularity of open-vm-tools. If there was more package granularity, then the perl dependency could be handled better since only one plug-in requires perl. *** Bug 1539802 has been marked as a duplicate of this bug. *** Note I have made this bug public now because a duplicate was reported by a member of the public who couldn't see this one. I'm assigning this bug to myself. Ravindra please continue to work this issue. We discussed the following on call this morning - The perl dependency comes from the deploypkg plug-in. There are three use cases for this plugin. First is to clone a template and customize guest on initial boot using vSphere’s customization feature. Second is to re-customize by SRM after a failover. Third is to re-customize the clone of a running VM using the instant clone feature. In addition, if customer is using cloud-init to do customization, then there is a dependency on python If they are using legacy customization method, then there is a dependency on perl. Not all customers use the above features, so it is undesirable to force all users of OVT to install perl. Many security sensitive customer would not want to have perl installed. We don’t see a good solution to this. Would like to close this as Won’t Fix. I read from the comment above that three of three use cases require perl. If that's true, then adding a requirement seems very simple: %package deploypkg requires: perl : If we want to avoid perl, that's an easy enough sell -- not for any deficiencies, but to avoid the dearth of one-off tool installs where it can be avoided. Switching to something like sed may be simpler, as it's usually installed; but that would take some coordination with the organization and team who built deploypkg to finish the job. Based on VMware's rationale in comment 30, closing this as WONTFIX for this version of open-vm-tools. The preference is to avoid having all customers install perl for only a few use cases that are used by some customers. If you have a strong objection, please re-open. *** Bug 2035202 has been marked as a duplicate of this bug. *** VMware's issue in comment 30 was interesting because this issue is only exposed in cases where the integrator wants to use the tool but hasn't automatically installed perl. It's ironic that their objection to shoveling dependencies to fix the tool is an objection to a situation only seen when people are trying to avoid dependency-shoveling according to the very same ideals. Comment 31 is an effort to address those concerns and still solve the simple dependency problem. In that context, we chose to just close the ticket in comment 32. Was closing it the best choice, when 2.5 years later the issue is still seen for people who haven't shoveled perl into their project already? Can we consider re-opening this ticket for a one-liner fix? |