Re: Towards multi-arch: "Multi-Arch: same" file conflicts
On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 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.
>
/usr/lib/<tuple>/package/ is more natural with Autotools and CMake,
which I prefer to use.
> 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.
>
Yes, detecting endianness at compile time and setting substvar is
easy, but again if those packages are arch:any, then they'll actually
consume a lot of space on our mirrors (discussed at -devel before).
>> 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.
>
If we want to reduce the mirror space consumed by such a package,
building arch:all package is a straightforward solution without
modifying archive management software and dpkg/apt, but it's again not
a good choice because we have to keep using binary upload mechanism
(or the maintainer will be required to patch the software so it can
generate both be/le data during a single buildd run).
> 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
I agree on your opinion. It's much better than nothing. But we do need
to discover possible solution for Wheezy+1 or even Wheezy+2, don't we?
:-)
--
Regards,
Aron Xu
Reply to: