Bug 1566459
| Summary: | python-devel ships .exe files | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Tomas Tomecek <ttomecek> | |
| Component: | python | Assignee: | Python Maintainers <python-maint> | |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.4 | CC: | cstratak, jkejda, mhroncok, pviktori, rfontana, vstinner | |
| Target Milestone: | rc | Flags: | rfontana:
needinfo+
|
|
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1633219 1633220 (view as bug list) | Environment: | ||
| Last Closed: | 2019-02-18 10:55:22 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: | 1630906 | |||
|
Description
Tomas Tomecek
2018-04-12 11:11:46 UTC
These files are stubs that get included in an archive to build Windows executable installers. (e.g. `python setup.py bdist_wininst`) Removing them will disable this functionality. See these Fedora bugs for context: https://bugzilla.redhat.com/show_bug.cgi?id=525469#c5 https://bugzilla.redhat.com/show_bug.cgi?id=1426257 We can remove these, but I need guidance on the "Windows SDK license issue". Should these files be removed from the SRPM also, or are they OK there? ping. Can you please answer? Debian doesn't distribute wininst*.exe binaries in their python* packages. debian/rules explicitly removes thesee files: find $(d) -name 'wininst*.exe' | xargs -r rm -f The PSF is taking way too much time to respond. We need to do this downstream. On my Fedora 28, "python3 setup.py bdist_wininst" fails early because the code is really written for Windows:
$ python3 setup.py bdist_wininst
(...)
creating dist
Traceback (most recent call last):
(...)
File "/usr/lib64/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "/usr/lib/python3.6/site-packages/setuptools/command/bdist_wininst.py", line 19, in run
orig.bdist_wininst.run(self)
File "/usr/lib64/python3.6/distutils/command/bdist_wininst.py", line 179, in run
self.create_exe(arcname, fullname, self.bitmap)
File "/usr/lib64/python3.6/distutils/command/bdist_wininst.py", line 262, in create_exe
cfgdata = cfgdata.encode("mbcs")
LookupError: unknown encoding: mbcs
Removing .exe files from a Linux package is fine since the command never worked anyway on Linux.
Python Software Foundation replied back: -------------------------- Hello, Shipping and distributing these files is ok. These files are stubs, used as the executable part of a self-unzipping executable and showing an "installer window" to the user. They are original to Python and, while they call win32 functions, they don't have Windows SDK code in them.The source is at: https://github.com/python/cpython/blob/master/PC/bdist_wininst/install.c The binaries are included so that anyone creating a bdist_wininst distribution (mostly deprecated, actually) can do so, even when cross-compiling. Thanks, Van -------------------------- So: * we don't need to include the exe files in the built packages * we don't need to strip them down from the SRPM On Python 2, bdist_wininst currently works. We need to provide a good error message, for example: Support for xreating Windows installers using bdist_wininst was removed for legal reasons. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1566459 Remove .exe can break legit applications running on RHEL7, whereas VanL, the PSF Layer, wrote that it's asafe to distribute these .exe files. See the discussion starting at: https://mail.python.org/pipermail/python-dev/2018-October/155507.html > asafe
Oops, typo: you should read "safe" obviously :-)
|