Hello all,

I'm trying to figure out the best way to handle cross-architecture
installations.  Right now, I can create a pretty much bootable RPi 3
image with KDE using this command:

apk --arch aarch64 --root /path/to/sdcard -X
https://distfiles.adelielinux.org/adelie/1.0/system -X
https://distfiles.adelielinux.org/adelie/1.0/user --initdb add
adelie-base-posix kde x11

However, some packages fail to install properly if the host computer
isn't aarch64.  Notably, this includes D-Bus, which needs to generate a
machine ID during installation:

== user/dbus/dbus.post-install ==

#!/bin/sh

exec dbus-uuidgen --ensure


This doesn't work because dbus-uuidgen is in the SD card root.  It is an
ARM binary, not a PowerPC binary as my host system expects.  So we end
up with: Exec format error.

It's possible to pass --no-scripts to apk to avoid the attempted
execution of these scripts, which would then prevent world from being
marked broken on the SD card.  This would silently break D-Bus, though.

Alternatively, one could set up a oneshot service to run 'apk fix' on
first system boot.  My concern is that it would have to pull the apks
off the network, which could be slow or even non-existent.

As you can see, neither of these options are very appealing.

Does anyone have any ideas on how we could handle this usage?  One idea
I had was to add a --scripts-only flag to apk fix, to avoid redownload
and reinstall of the package and simply re-run any scripts that have
failed execution.

I suppose some scripts may need to be reworked to handle being called
multiple times, but this shouldn't be a large issue and is probably a
good idea from a correctness perspective anyway.

However, I'm open to other ideas.  Let's discuss!

Best,
--arw


-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org

I did the approach you did - a one-time apk fix - with my RISC-V work,
and it works reasonably well. The main alternative is using qemu-binfmt
to run foreign binaries in a chroot.

Hi,

On Sun, 9 Feb 2020 05:02:07 -0600
"A. Wilcox" <awilfox@adelielinux.org> wrote:

> I'm trying to figure out the best way to handle cross-architecture
> installations.  Right now, I can create a pretty much bootable RPi 3
> image with KDE using this command:
> 
> apk --arch aarch64 --root /path/to/sdcard -X
> https://distfiles.adelielinux.org/adelie/1.0/system -X
> https://distfiles.adelielinux.org/adelie/1.0/user --initdb add
> adelie-base-posix kde x11
> 
> However, some packages fail to install properly if the host computer
> isn't aarch64.  Notably, this includes D-Bus, which needs to generate
> a machine ID during installation:
> 
> == user/dbus/dbus.post-install ==
> 
> #!/bin/sh
> 
> exec dbus-uuidgen --ensure
> 
> 
> This doesn't work because dbus-uuidgen is in the SD card root.  It is
> an ARM binary, not a PowerPC binary as my host system expects.  So we
> end up with: Exec format error.
> 
> It's possible to pass --no-scripts to apk to avoid the attempted
> execution of these scripts, which would then prevent world from being
> marked broken on the SD card.  This would silently break D-Bus,
> though.
> 
> Alternatively, one could set up a oneshot service to run 'apk fix' on
> first system boot.  My concern is that it would have to pull the apks
> off the network, which could be slow or even non-existent.
> 
> As you can see, neither of these options are very appealing.
> 
> Does anyone have any ideas on how we could handle this usage?  One
> idea I had was to add a --scripts-only flag to apk fix, to avoid
> redownload and reinstall of the package and simply re-run any scripts
> that have failed execution.
> 
> I suppose some scripts may need to be reworked to handle being called
> multiple times, but this shouldn't be a large issue and is probably a
> good idea from a correctness perspective anyway.
> 
> However, I'm open to other ideas.  Let's discuss!

Yes, this is something I've been thinking also a bit earlier. But it's
fundamentally an upstream problem if one needs to run the
pre/post/trigger script. 

Of course this is limited to packages needed to be installed form the
host on different architecture.

Some options are:

1) Try to get rid of these scripts. Perhaps some could be moved to
init.d stage.

2) Think if we can make scripts be run on the host instead. That have
the cross builder install the same packages on host, and use it's
binaries to run on the target root. This would require awareness of the
scripts that it should be targetting chroot, and apk awareness of
checking host packages. Though, this does not work if upstream has e.g.
arch specific format on the data the utilities launced in the script
produces. Or if it's trying to dlopen the libraries on the target
plugin directory.

3) Have a generic initscript for apk that runs all pending scripts.
This will become possible in the new architecture since we will store
all scripts in the database in future.

Maybe you have additional ideas?

Thanks,
Timo