[Bug 588941] Review Request: pypy - Implementation of the Python language, using Python itself

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=588941

--- Comment #34 from Dave Malcolm <dmalcolm at redhat.com> 2010-12-17 07:35:34 EST ---
(In reply to comment #33)
> JVM backend is not mature enough to be shipped. 
Thanks; we'll leave it out, then.

> Btw: how did you end up having
> those files in the first place? Only things that are needed for a binary are
> ones that are packaged using package.py, which includes stdlib and .h files
> (and that's about it). Do you put all the source code with the package? If so,
> why?
Sorry, it's not clear to me which files you're referring to in the above.

The specfile is still using the scripted code from before; I haven't yet looked
at the package.py you referred to.  I plan to address this later today (note to
self: comment #12 above).


> Regarding time - it was said here before I think, but using pypy to build pypy
> is already saving half of the time. That said, what I did when building ubuntu
The specfile is written with the potential to build other configurations
(stackless currently), and it use the ./pypy (i.e. the JIT-enabled binary) if
it's already been built within this build.


> packages was simply replace the translate.py option with copying of already
> built pypy-c, this way it was much more convinient (do you also build KDE from
> scratch each time you want to test something on a package building process?)
I'm not sure I understand the analogy here.  Source RPMs are the granularity we
work at when doing rebuilds.  So we don't rebuild GCC each time, if that makes
sense (and eventually you get into "Reflections on Trusting Trust" territory).

If you're referring to using a pypy-c supplied as part of your tarball: we
avoid using binaries supplied by upstream as a general policy across all of
Fedora:
  - we want to ensure that we always can regenerate the full OS from source,
using a fully open-source toolchain, and using binaries from an upstream
tarball make it harder to assert that property of our OS.
  - avoiding prebuilt binaries reduces the knock-on effect of an upstream
repository getting Trojanned
More information on this policy is here (if bz doesn't mangle the link):
http://fedoraproject.org/wiki/PackagingGuidelines#No_inclusion_of_pre-built_binaries_or_libraries

There are exceptions allowed for compilers and cross-compilers, but as I
understand it, they are intended for when someone is bootstrapping the
buildsystem on a new architecture.  My gut feeling is that the speedup, whilst
desirable, doesn't outweigh the benefits of knowing that every binary was built
in the same highly locked-down environment (e.g. we have a fresh chroot for
every build, which we can reconstruct if we need to go back to investigate
something).

Another way to do this is: once a pypy package is in Fedora, it could have a
build-time requirement on itself (i.e. build a new pypy package using the old
one each time).  Loops in the build-time dependency graph make me nervous; we
try to minimize them, since it makes doing a full rebuild of source of all of
Fedora more difficult (e.g. when introducing a new version of GCC).

Hope all of the above makes sense (it's too early in the morning here)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.