On 02/24/2017 05:17 PM, Petr Pisar wrote:
I'm reviewing rakudo <https://bugzilla.redhat.com/show_bug.cgi?id=498390>,
a Perl 6 interpreter. The interpreter is mostly written in NQP language and
the sources are compiled into MoarVM object files at RPM package build time.
The moarvm files are installed under /usr/share subdirectories.
The problem is the moarvm files differ in size (and thus in content) among
architectures.
My first impression was that the files must be moved under %{__libdir}. But
I'm not fully convinvced it is really necessary.
Provided what you say, this would be the way to go, IMHO.
First, the moarvm files should be portable despite of different size. At least
this my unverified opinion. If it were true, could we put the files into
a noarch subpackage? Wouldn't that break Fedora release managament?
Second, if rakudo did not aspire for multilib safety (rakudo contains some ELF
files), would it be permissible to keep the moarvm files under /usr/share and
delivered by architecture-specific RPM package?
Short answer: no.
Maybe my questions could be summarized as: How should the FHS definition ("The
/usr/share hierarchy is for all read-only architecture independent data
files") should be understood?
Imagine /usr/share was nfs-mounted and shared between all thinkable OSes
and architectures.
The files must be bit-to-bit indistinguishable,
or the files can be used on any architecture?
In my understanding, we (FPC) have treated /usr/share as bit-to-bit
identical.
Ralf
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
