We agree that using MIME type suffices like "*.py" as a selector is
intrinsically flawed.
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.
The core of the problem (and the source of the above assumptions) is the rather
poorly written bro-Python-byte compile script.
And the problem needs to be solved, not band-aided with enablers and disablers
and distro packaging policies packaging conventions.
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.
Entirely equivalently, some of the "exit 1" lines in the script could be
eliminated: an entire rpmbuild does not need to be failed to inform some Fedora
Python packager that the country code for Paraguay happens to collide with the
extension typically used for Python interpreter sources.
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.
But adding rpm macro disablers instead of fixing the assumptions coded into
brp-python-bytecompile makes little sense to me.
--
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-384042734
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
