https://bugzilla.redhat.com/show_bug.cgi?id=498390 --- Comment #61 from Petr Pisar <ppisar@xxxxxxxxxx> --- (In reply to Petr Pisar from comment #36) > If the moarvm files were portable (could you try overwriting e.g. the x86_64 > files by i686 files and check that rakudo still works?), then keeping the > files under /usr/share, but packaging them into noarch sub-package could > work (i.e. comply to packaging guidelines and not break Fedora > infrastructure). > > I think the best thing would be ask rakudo developers why they chose > /usr/share and if the files are indeed portable. > Upstream answer is: The bytecode, strings, callframe info, and debug annotations forth are all certainly portable. That leaves the serialized objects blob, which represents a bunch of objects and types. In Perl 6 terms, this stores stuff like meta-objects, code objects, signatures, parameters and so forth - but also the results of all BEGIN-time computation including constants. The objects serialized on, say, a 64-bit LE architecture can be deserialized on a 32-bit BE architecture, for example. Indeed, we rely on this, since we store a single stage0 binary compiler in the NQP repository, which is used as the base of the bootstrap. However, users can do anything they want at BEGIN time, including using things such as $?BITS which will be platform-dependent. This means that a .moarvm file potentially can end up being platform-dependent. -- You are receiving this mail because: You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx