[mythtv-commits] Ticket #13505: Rewrite python shebangs during 'make install' step

MythTV noreply at mythtv.org
Mon Dec 30 04:09:04 UTC 2019


#13505: Rewrite python shebangs during 'make install' step
-------------------------------+--------------------------------
 Reporter:  rcrdnalor          |          Owner:  Raymond Wagner
     Type:  Patch - Feature    |         Status:  new
 Priority:  minor              |      Milestone:  needs_triage
Component:  Bindings - Python  |        Version:  Master Head
 Severity:  medium             |     Resolution:
 Keywords:  python shebang     |  Ticket locked:  0
-------------------------------+--------------------------------

Comment (by Gary Buhrmaster):

 > But as I said already, I do not know QMAKE well.

 Discussion:

 I am not sure many do (I know I do not know it well either (I mostly just
 tolerate qmake), maybe one of the MythTV devs would be considered an
 expert).  That there are so many websites dedicated to the hidden and
 undocumented features and capabilities probably says something important
 about qmake itself.  It should be noted that qt company (and its
 predecessors) itself created qbs to try to deal with some of the qmake
 issues, but has more recently deprecated even qbs, putting more resources
 into cmake as a cross platform build option moving forward based on
 customer feedback.

 The qmake way to deal with script modification would seem to be using the
 QMAKE_EXTRA_COMPILER stanza to convert the files to the eventual target
 content (as the transformation is something akin to a compilation), but
 while I initially considered do so (had some code fragments doing it), the
 advantages did not seem to outweigh the added complexity (and even more
 under documented stanzas needed for providing your own "compiler"), so I
 agree with your approach that using the extra member seems more
 straightforward (as the least bad option).

 That said, there are a couple of things that I noted when I looked at both
 the existing pro file, and at the proposed patches in this ticket, some of
 which were inherited from the original .pro file, and some of which are
 from the proposed patches:  (a) make uninstall does not work, (b) one
 should not use #!/usr/bin/env for a packaged binary(1), (c) the shebang
 does not specify the actual binary (related to, but different, from the
 improper use of /usr/bin/env)(2), (d) A shell script may not work in
 certain non posix environments, (e) the installed scripts are not properly
 installed based on bindings (installing scripts that are not executable
 due to dependencies not installed (the perl scripts require the perl
 bindings, the python scripts require the python bindings)).  Except for
 (b) none of which are probably critical to address, but once one looks at
 code, more and more issues tends to be seen.


 (1) A #!/usr/bin/env shebang has a somewhat storied history, and while
 there are those that still write it for their own personal use, the
 general consensus is that use of it is considered (strongly) discouraged
 for installed executable use because it depends on what the user running
 the program might have setup in their environment, potentially resulting
 in subtle, or not subtle, issues, and one should get repeatable results
 for installed programs.  For some distros, more than discouraged, the
 /usr/bin/env shebang is banned from installed packages. Typically the
 python setup modules sets the shebang to the python that it is called with
 (for this example, let us call it #!/usr/bin/python3) when copying
 scripts, as it done for the mythpython and mythwikiscripts from the
 bindings directory.  This is considered correctness.

 (2) python distutils defaults to replacing and shebang with the actual
 executable used for setup.py (or equivalent).

 Proposed action:

 I will attach my alternative patch proposal, which address the issues I
 have identified.

 Future enhancements:

 A number of the python files in the .../programs/scripts/ directory suffer
 the same issue with having errant shebangs or executable bits that are not
 correct (similiar to #13539 and #13540 ).  But as they are essentially
 benign at the moment, I do not plan on prioritizing working up a patch for
 them.

-- 
Ticket URL: <https://code.mythtv.org/trac/ticket/13505#comment:3>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list