on the semi-offtopic python .pyc timestamp issue see:
https://github.com/python/cpython/pull/296
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for the patch!
--
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/144#issuecomment-280306290___
Rpm-maint mailing list
Merged #144.
--
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/144#event-964822197___
Rpm-maint mailing list
@fweimer I see, that makes much more sense.
--
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/144#issuecomment-278350760___
@Conan-Kudo:
> Wouldn't that happen during the package build, rather than at runtime? It
> seems like that's a package build-time action.
I quoted the wrong part (Github doesn't seem to support automated quoting). I
was actually referring to this:
> I was thinking that it would be better to do
@ffesti I restructured the code to get rid of the ugly 'static' globals.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@bmwiedemann wrote:
> The alternative approach would be to change the macro generating them and
> first touch source .py files to set their date to $SOURCE_DATE_EPOCH so that
> this gets embedded in .pyc headers
I doubt that RPM can do this without delayed script execution because the
@toabctl I'm not particularly a fan of the late byte-compilation technique
Debian uses, and I'd rather not propagate that down to everyone.
However, @bmwiedemann's idea of getting the .py files set to
`$SOURCE_DATE_EPOCH` to embed that in .pyc files is interesting.
--
You are receiving this
On 2017-02-02 13:46, Florian Festi wrote:
> I am not too keen on the use of global variable
Do you refer to "oneshot" or "SOURCE_DATE_EPOCH"?
> I wonder how we want to address the Python .pyc file issue
I was thinking that it would be better to do it like Debian and generate
those in %post
I am not too keen on the use of global variable(s) here. May be we can renew
loading the environ variable for each build and store it in the spec or package
variable instead.
While it may not matter much in practise I'd rather not like to add more
technical debt there.
Other than that the
10 matches
Mail list logo
