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 #35 from Maciej Fijalkowski <fij...@gmail.com> 2010-12-17 07:46:09 EST --- (In reply to comment #34) > (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). > I'm referring to prebuilt jars. They should not be there in the binary distribution at all, because the source code is not included (or a directory where they live in). How did you get a list of files that has to be included? > > > 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) Heh, hope your coffee tastes good :-) I'm not referring to the build process for a distribution itself (that should be fairly constrained, I admit) and while pypy would be cool to have, it's not more than "suggested" for a pypy build. What's I'm referring to is that when you work on a build system you might want to avoid the whole translation process at all, by say copying already built pypy binary and avoiding burden associated with creating it each time. you would still need to build one for the distribution though (but the length of build process is not as painful). That's just a suggestion and I guess I'm not getting the whole complexity of things associated anyway. Cheers, fijal -- 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. _______________________________________________ package-review mailing list package-review@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
