Thank you!
--
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-392505340___
Rpm-maint mailing list
Closed #434 via d5e599d6c9b2fc5c98cec1fccc46e2d365a06dbf.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Changed as requested.
--
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-390944663___
Rpm-maint mailing list
Passing `%{?__python}` was copied from Fedora. The script seems to expect it. I
can pass `""` here instead, as the invocation differs in Fedora anyway.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Passing %{?__python} at least deserves it's own separate patch. It also
deserves some argumentation why it does not change the behaviour (it probably
does) or why the change is acceptable/desirabled.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
So I set `%_python_bytecompile_extra` to 1 as default. And the opt out is to
undefine it, opt in is to set it to 1.
Will do.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The new "extra" naming is much better, thanks.
Now that I look closer though: the enable/disable "functions" are very unlike
anything else in rpm, and there's no obvious default when it's handled that
way. Just drop them and use define/undefine of %_python_bytecompile_extra
control it
@hroncok pushed 1 commit.
d8a2025 fixup! Provide a way to opt out from automagic Python bytecompilation
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@hroncok I'd suggest calling the flag `%disable_extra_pybytecompile`, since
this is referring to "extra" byte-compilation outside of the standard Python
site-packages path.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We would like to proceed with the Fedora change and this here looks stalled.
Should we maintain a downstream patch instead?
@pmatilai Do you have a better suggestion for the name of the disable/enable
macro?
--
You are receiving this because you are subscribed to this thread.
Reply to this
> Handing the script to either Python programmers or distro QA engineers is far
> likelier to get timely fixes then in an upstream rpm release.
Note that we are fine maintaining this inside rpm, as long as you hear our
concerns.
--
You are receiving this because you are subscribed to this
@Conan-Kudo: And "Who maintains RPM?"
Expecting C programmers to maintain a shell script to make Python packaging
easy and uniform in several distro's is an exercise in politics, not
engineering.
Handing the script to either Python programmers or distro QA engineers is far
likelier to get
And what is the proper fix? The second part being ditched? I worry that's too
breaking. That's why we designed the Fedora change the way we did, keeping it
backwards compatible while providing a way out.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
I don't want to see this brp removed from the rpm tree, especially since every
single thing that gets unnecessarily split out and maintained independently
becomes more difficult to manage and update.
This brp script is relied on by several distributions, so I'd rather see this
properly fixed
So, the conclusion is to remove brp-python-bytecompile from rpm and maintain
our own?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The task is not "bytecompile it with a Python interpreter that won't fail". It
is "bytecompile it with the Python interpreter that will be used to import it".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Meanwhile, there is no reason I know of that an ordered list of python
> interpreters in PATH (or in /usr/bin if you must) cannot be tested for
> existence and use the first found interpreter to byte compile.
The reason is that the packager knows what are those py files for. Is it a
plugin
Au contraire: one can write magic pattern rules to match syntactical variants
of *.py and emit the interpreter to be used to interpret a file exactly like
MIME was designed for.
But I digress: writing correct/useful magic pattern rules based on syntax is
hugely fragile and a black art.
> 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
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.
Finally, the brp-python-bytecompile script should be moved out of rpm into some
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
> Why not just add an additional test for an executable bit on a \*.py file
> instead of attempting detection of within tree compilation?
What does this has to do with executable bits? You need to bytecompile files
that are imported, not the files that are executed. The problem with current
(after perusing the Fedora RFE explaining the change)
The failure example given has a confusion in the extension *.py (which can also
apparently is the country code for Paraguay).
Why not just add an additional test for an executable bit on a *.py file
instead of attempting detection of within
This is not disabling python bytecompilation. This makes the packager in charge
of what is compiled with what. I can hook in SELinux devs just to make sure.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You should likely coordinate the disabling of automagic byte compilation with
SELinux devels because at leas part of the reason why automagic byte
compilation was attempted is/was to ensure that excitable files created by
package installs would have security attributes attached/created by rpm.
* `disable_pybytecompile_outside_pythondir`
* `disable_pybytecompile_arbitrary_locations`
* ...?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
NAK, the name disable_automagic_pybytecompile strongly indicates that it
disables it *completely* but it does something entirely different.
If byte-compilation outside python libdirs is too magic and error-prone, I
think it's better to just drop it from the build root policy unconditionally,
ignatenkobrain commented on this pull request.
> %__brp_strip %{_rpmconfigdir}/brp-strip %{__strip}
%__brp_strip_comment_note %{_rpmconfigdir}/brp-strip-comment-note %{__strip}
%{__objdump}
%__brp_strip_shared %{_rpmconfigdir}/brp-strip-shared
%__brp_strip_static_archive
28 matches
Mail list logo
