On Sat, Jul 30, 2005 at 12:26:04PM +0100, Colin Watson wrote:
> On Sat, Jul 30, 2005 at 03:52:44AM -0700, Steve Langasek wrote:
> > On Sat, Jul 30, 2005 at 12:00:32PM +0200, Marc 'HE' Brockschmidt wrote:
> > > Listing Perl, Python and Emacs here is totally wrong (and I don't know
> > > enough about Java packaging to speak about it). Perl is the best
> > > example: Architecture-dependend data is stored in /usr/lib/perl{/,5/},
> > > arch-indep data in /usr/share/perl.
> > Not 100% true; /usr/lib/perl{/,5/} contain architecture-dependent binary
> > modules, *along with any architecture-independent wrappers that accompany
> > them*.
> Brendan O'Dea has said things along these lines before, I know, but I'll
> repeat it: those wrappers are in most cases rather tightly bound to the
> precise interfaces exported by the architecture-dependent binary
> modules. The fact that they happen to be expressed in a form which is
> the same on all architectures doesn't make them truly
> architecture-independent, as architectures with different versions of
> the binary modules would generally need different versions of the
> wrappers too.
> Files are put in /usr/share because one might want to mount that
> directory on multiple machines. If putting something on a hypothetically
> NFS-mounted /usr/share means that you have to keep /usr/lib precisely in
> sync across all the machines that mount it for fear of breakage, you
> have to ask whether this is really a beneficial thing to do.
But it's quite probable that there will be interdependencies between the
contents of /usr/lib and /usr/share and yet other directories, requiring
such strict synchronization. It's not uncommon that sharing /usr requires
fiddling with /etc across machines, even, but in particular I think that
trying to NFS share /usr/share is just not worth the pain anyway. That's a
major reason why I think multiarch is a good idea that's way overdue.
At any rate, I'm not exactly bothered that there is arch-independent data in
/usr/lib/perl; I'm just pointing out that it is a precedent.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature