Re: Towards multi-arch: "Multi-Arch: same" file conflicts
- To: Aron Xu <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: Towards multi-arch: "Multi-Arch: same" file conflicts
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Tue, 01 May 2012 15:25:22 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <CAMr=8w5UU+oJVTfhp-7OP6G4iJjDj7PDsi+N5JNQt_r3Kt0Zhw@mail.gmail.com> (Aron Xu's message of "Tue, 1 May 2012 04:37:52 +0800")
- References: <20111117190327.GA646@jwilk.net> <20120422132621.GK4238@radis.cristau.org> <20120426152120.GA21811@localhost> <CAMr=8w7Uy76EOW6y+-urPZunGWO11ndswb9q1T4EoRLms8A-cQ@mail.gmail.com> <firstname.lastname@example.org> <CAMr=8w7S7gRJ=PMmTSy0ZgMXgFdOe8az4AiaWSth1v=xa0TBnw@mail.gmail.com> <email@example.com> <CAMr=8w5UU+oJVTfhp-7OP6G4iJjDj7PDsi+N5JNQt_r3Kt0Zhw@mail.gmail.com>
Aron Xu <firstname.lastname@example.org> writes:
> On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow <email@example.com> wrote:
>> Aron Xu <firstname.lastname@example.org> 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
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.
> 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.