On Thu, Jul 20, 2023 at 08:28:23AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Hi Adrian,
Hi Josch,
> thank you for weighing in!
>
> Quoting Adrian Bunk (2023-07-20 01:27:10)
> >
> > Package: box64
> > Architecture: amd64 arm64 ppc64el riscv64
> > Depends:
> > libgcc-s1:amd64,
> > libstdc++6:amd64,
> >
> > A package must not assume that the user has other architectures enabled.
>
> why not? Is this codified in a policy somewhere? If foreign architectures are
> not enabled, box64 would just not be installable but there are tons of
> packages
> I cannot install on my system without the package itself being buggy (for
> example due to Conflicts).
>...
testing migration checks that for every binary package from the source
package there exists a configuration where it can be installed,[1] and
that the migration does not make any other binary package currently in
testing uninstallable on any architecture.
E.g. an alternative init system must be installable, but it can
obviously not be installed at the same time as the default init system.
There is not even a requirement that all binary packages from a source
package can be installed at the same time (often this is not possible).
> If I just drop these dependencies, that would make the package have an RC bug
> because box64 cannot function without amd64 shared libraries.
Yes.
>...
> It seems that the correct way forward would be to teach britney about foreign
> architecture dependencies? I had a look at the britney source and it seems to
> ship with its own dependency resolver instead of relying on dose3, for
> example.
> Teaching it about foreign architectures looks like a massive change...
>...
This would be a huge can of worms in many places, for relatively fringe
usecases.
My first question would be whether all dependency resolvers apt might
use support it properly.
And the higher level issue how your package should be used on derivates
that do not support all architectures, which is not uncommon for exactly
the kind of hardware your package is intended for. Should [2] also be
required to ship packages for all other Debian release architectures
like amd64 and s390x?
>...
> > For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might be
> > an
> > option (untested).
>
> Those packages install their libraries into /usr/<triplet> which is not
> searched by the dynamic linker. Maybe some LD_LIBRARY_PATH trickery can make
> it
> work but those shared libraries are not meant for running actual binaries.
Just make the hardcoded location in the sources of your package configurable:
src/steam.c: strcpy(tmp,
"BOX64_LD_LIBRARY_PATH=/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:");
src/main.c: if(FileExist("/lib/x86_64-linux-gnu", 0))
src/main.c: AddPath("/lib/x86_64-linux-gnu", &context->box64_ld_lib, 1);
src/main.c: if(FileExist("/usr/lib/x86_64-linux-gnu", 0))
src/main.c: AddPath("/usr/lib/x86_64-linux-gnu", &context->box64_ld_lib,
1);
src/wrapped/wrappedlibdl.c: if(!strcmp(rfilename,
"/usr/lib/x86_64-linux-gnu/d3d")) {
> Thanks!
>
> cheers, josch
cu
Adrian
[1] For binary-all this is not required for all architectures and only
checked for amd64 and arm64.
[2] http://raspbian.raspberrypi.org/raspbian/dists/bookworm/
