[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch and idea for improved diversions and alternatives handling

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.


(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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: