Re: GNUstep and FHS
On Sat, Jul 30, 2005 at 02:55:53PM -0700, Steve Langasek wrote:
> On Sat, Jul 30, 2005 at 12:26:04PM +0100, Colin Watson wrote:
> > 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.
(Those would presumably be expressed by tightly-versioned dependencies
among binary packages, where necessary. I could imagine an automatic
scheme that spots when architecture-dependent binary packages are
upgraded on one machine in a group and goes off to upgrade them on all
the others.)
> 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.
I tend to agree with you. In that case, I have to ask what the point is
of getting het up about whether something's in /usr/share, if we don't
think it's generally worth people's while actually sharing it. I can see
why we should be strict about not allowing architecture-dependent files
in /usr/share, since the few people who *do* actually share it would be
seriously inconvenienced by that; but what important problem are we
solving by being strict about architecture-dependent files in /usr/lib?
My opinion is that being strict about whether files are in /usr/lib when
they shouldn't be isn't solving any sufficiently important problem to
consider it release-critical, and that packages should be allowed to
deviate from this and use /usr/lib alone when it is extraordinarily
difficult to distribute them properly across the hierarchy (as is
apparently the case for GNUstep).
The situation seems to me to be very similar to the question of whether
architecture-independent data should go in a separate Architecture: all
package or be part of some related Architecture: any package; in the
past consensus has been that large chunks of data should generally be
split out, but we've certainly never considered it release-critical if
it isn't.
> 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.
Right.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: