Re: Multiarch and idea for improved diversions and alternatives handling
* Neil Williams
(Please respect my Mail-Followup-To and my Mail-Copies-To: never)
| On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote:
|
| > 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?)
Yes.
| A single subdirectory of /usr is, IMHO, neater than a subdirectory
| of /usr/include and /usr/lib/.
It would be a subdirectory of / as well.
| 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.
I think it'd be about as ugly as having /$triplet anyway.
| > | /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.
Part of the point of multiarch is we don't actually need to make major
changes. We need to do some fairly localised changes.
| > | 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.
Or we could get the file exclusion branch in dpkg applied and add
support for excluding files based on the arch of the package being
installed. Voila, no problems with file conflicts in /usr/share.
| > 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.
This bit has been public and on the table at least since I wrote my
master thesis in 2005. :-P I don't think anybody has suggested
anything else since then.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: