On Mon, Aug 01, 2005 at 05:34:17PM +0100, Colin Watson wrote: > 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.) Yah, this kind of dependency can also certainly exist between files within a single package. > > 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? FWIW, I don't think /usr/share vs. /usr/lib is the biggest issue in GNUstep. I think the bigger issues are: - shared libs in /usr/lib/GNUstep/foo instead of in /usr/lib (has been done by other packages in the past, but it looks like my historical example, mozilla, has been cleaned up) - ObjC headers in /usr/lib/GNUstep/bar instead of in /usr/include; it's not clear whether this is actually an FHS violation, since the FHS says C/C++... :) - manpages apparently duplicated under /usr/lib/GNUstep/System/Library/Documentation/man/manX/ - user-executable binaries under /usr/lib/GNUstep/baz instead of in /usr/bin > 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). Do the above data points change that assessment any? Also, FWIW, if multiarch *is* the answer for users trying to deploy systems that share bits across the network for multiple architectures, then proper delineation of /usr/share vs. /usr/lib becomes all the more important... -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature