Re: Towards multi-arch: "Multi-Arch: same" file conflicts
Aron Xu <happyaron.xu@gmail.com> writes:
> But what if I endianness does matters for those gettext .mo files?
> Installing them as libfoo-translations-be and libfoo-translations-le
> will need some change in gettext support of those
> applications/libraries, that is finding mo files in alternative paths,
> and choosing the right one when being built (cross or not) and run
> (host or qemu).
Yes it does. Or maybe not. Lets talk about the general case instead of
gettext (gettext uses /usr/share/... so they must be arch independent).
With libfoo being in /usr/lib/<M-A tuple>/ any endian dependent data
should be in /usr/lib/<package>/<M-A tuple>/ or /usr/lib/<M-A
tuple>/<M-A tuple>/ (sorry, did we pick one of them as standard yet?),
which is usualy a configure option.
When the files are moved into libfoo-data-be then you can put links in
/usr/lib/<package>/<M-A tuple>/ or /usr/lib/<M-A tuple>/<M-A tuple>/ to
link to /usr/lib/<package-data-be/le>/.
> Apart form (possibly) patching the software, marking the library as
Not the library, only the data files.
> M-A:foreign is questionable. How do we specify dependencies in
> d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
> on different architectures, do we really want to hard code which
> architecture to depend on which package manually?
For the moment I don't see any other choice. If this is a frequent
problem then some dpkg support could be added or some debhelper
tool. Detecting the endianness at compile time and setting a substvar
would be relatively easy even now.
> Generating data files for both be and le then making it an arch:all
> and M-A:foreign package is not a solution for all maintainers, as this
> requires to patch the software which upstream are tend to reject of
> inclusion in many cases. Generating such data files in maintainer
> scripts is another thing I hate because I believe these data meant to
> have checksum stored in the package file list so that users can verify
> its integrity when needed.
There is no one solution for all maintainers.
At the moment and given the closeness of the freeze I would just do
whatever works for now. If that means big and little endian flavours of
the library have to conflict (libfoo-data-be conflicts libfoo-data-le)
because the path can't be untangeled then I would still think that would
be better than no multiarch support at all. The most common case is
amd64+i386 and adding armel is probably the next common. So most
multiarch users would be ok.
MfG
Goswin
Reply to: