[Rpm-maint] [rpm-software-management/rpm] Provide a way to opt out from automagic Python bytecompilation (#434)

Petr Viktorin notifications at github.com
Tue Apr 24 19:24:22 UTC 2018


> We agree that using MIME type suffices like "*.py" as a selector is intrinsically flawed.

Yes.

> Equally flawed is, say, assuming that Python is always installed on prefixed paths that match the pattern "/usr/lib(64)?/", or in, say, a sub directory "pythonX.Y" implying that /usr/bin/pythonXY should be invoked to byte compile.

True. However, it *is* reasonable to assume that every `*.py` file under `/usr/lib(64)?/pythonX.Y` should be byte-compiled with pythonX.Y.
For files outside the dedicated directory, byte-compilation should be invoked manually.

> The core of the problem (and the source of the above assumptions) is the rather poorly written bro-Python-byte compile script.

Yes.

> And the problem needs to be solved, not band-aided with enablers and disablers and distro packaging policies packaging conventions.

True. But, it needs to be solved in a way that doesn't break all packages that use it at once.

> The traditional way to solve suffix/path based pattern rules in a script like bro-Python-byte compile is to invoke file(1) to apply heuristics to content to determine whether the contents of a "*.py" file look like Python.

But, file(1) can't give you the interpreter to use – is it `/usr/bin/python2` or `/usr/bin/python3`?

> If an expert user truly needs control over some pathologically rare case where the automagic byte compilation needs to be disabled, the execute bit is a heuristic that associates a mode bit with a Boolean enabler that is consistent with other similar usage cases in rpm scripting, specifically #! interpreters, and ELF DSO libraries/modules/executables.

Unfortunately, the execute bit already has a different meaning: it means that a file is executable.
Most (but not all) files that need byte-compilation are *not* executable (and should *not* have a shebang).

> We also agree that automagic byte compilation needs to be phased out, and the tsunami change involved with python2 -> python3 is as good a time to rethink ancient rpm practice is as good as any other alernative.

Yes.

> Finally, the brp-python-bytecompile script should be moved out of rpm into some python-* package so that Python packagers can do whatever they wish and the rpm-build package does not need a dependency on python in order to be installed.

+1

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/434#issuecomment-384050391
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180424/74bd41db/attachment.html>


More information about the Rpm-maint mailing list