On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: > * Neil Williams > > | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all > | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire > | package under that, as we do with dpkg-cross currently: > > How would you then handle libraries that go in /lib? (Apart from the > fact that I think just using a subdirectory of /usr/lib is much neater > than random subdirectories in /usr. /lib/ /arm-linux-gnu/lib/ (did I miss that bit?) A single subdirectory of /usr is, IMHO, neater than a subdirectory of /usr/include and /usr/lib/. It would also mean less changes for those who are currently using multiple architectures on one system for the purposes of cross building. I wouldn't want to go the whole hog though and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be ugly, at least to me. > > | /usr/include/ > | /usr/arm-linux-gnu/include/ > > Please note that the initial goal of multiarch at least has been just > running of packages from foreign architectures. Not building them. True but the current usage of these mechanisms is in cross-building so sometimes the results of having to do something without major changes elsewhere can be helpful in designing the subsequent mechanism. > > | multiarch could even add: > | /usr/share/ > | /usr/arm-linux-gnu/share > > Pardon my language, but this is crack. The point of /usr/share is you > can share it between systems. If you go down this route, just use a > chroot and some wrapper scripts to bounce between them instead. It was only a suggestion for /usr/share - it was an alternative to renaming the package to get a different directory in /usr/share/ as the current tools do. Until all suitable packages have things like translations separated out into TDebs and other things like images in a -data or -common package instead of being packaged along with the architecture-dependent binaries, conflicts will occur if /usr/share is used as intended. Personally, I think it is better to avoid the need for complicated changes to diversions, alternatives or Replaces: if a simpler change in the packaging can achieve a smoother effect overall - albeit that the change in packaging would affect a lot more packages. Multiarch isn't needed for every possible package - not even every lib package or every binary package, changes can be made in the relevant package when people find a need to use that package as a multiarch package. > > [...] > > | BTW I think it is a mistake to want to use /usr/lib/i386/ when it is > | entirely possible that multiarch users will actually need the full > | triplet - think about hurd or kfreebsd as multiarch packages. > > I don't believe anybody has suggested using just /usr/lib/i386, but > rather /usr/lib/i486-linux-gnu? OK - as I said, my connection has been flaky and I might have missed that bit. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part