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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
