Aron Xu <happyaron...@gmail.com> writes:
> On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow <goswin-...@web.de> wrote:
>> Aron Xu <happyaron...@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.
Ok, lets stick with that then.
>>> 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
For example:
echo >>debian/$(PKG).substvars "endian:Depends=libfoo-data-$(shell
dpkg-architecture -qDEB_HOST_ARCH_ENDIAN)"
> 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).
Just for wheezy: Does that matter?
We aren't talking about many package and not a lot of data (yet). I
totaly agree that in the long term it is a terrible solution to
duplicate all the data for all archs when we only need 2 copies.
But at the moment I'm more concerned to get something that is
installable in wheezy. As long as the solution isn't too hard to get out
of again for wheezy+1 I don't quite care so much about mirror space.
>>> 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
That would be fine with me for wheezy if the maintainer is ok with that.
> (or the maintainer will be required to patch the software so it can
> generate both be/le data during a single buildd run).
If the software can generate both that usualy means it can also easily
use both and then you don't need the be/le destinction anymore. That is
the ideal solution. But not always feasable, esspecially not for wheezy.
>> 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?
> :-)
Yes. Just keep the two discussion ('what to do now' and 'what to do long
term') clearly seperate. So far I've only been concerned with the NOW part.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762cg11a5.fsf@frosties.localnet
