Re: [PATCH v2 1/6] sdk: Add support for adding self-defined sdk packages

[Baurzhan Ismagulov <ibr@radix50.net>]

Hello Jan,

On Mon, Jun 08, 2020 at 12:22:26PM +0200, Jan Kiszka wrote:
> I just realized another design issue with current sdk building:
> sdkchroot is shared with all image recipes that request
> do_populated_sdk. You may expect that defining SDP_[PRE]INSTALL there
> would have any impact, but that's not true therefore. Only adding those
> to an appended sdkchroot recipe or the global configuration works right
> now. As these additions may very well be specific to individual target
> images, neither of those options are perfect. We rather need to make the
> sdkchroot specific to the target image requesting it.
> 
> That said, such a rework could happen later because the current form is
> already fine for a lot of use cases (and is being used for a longer
> while now).

Thanks for the heads up, this was not on our radar. Let me check it and get
back to you.

Our comments so far:

1. I think the series is a good improvement, thanks.

2. isar-apt is added to the SDK so that the developer can install anything
   after the initial preparation of the SDK. E.g., the user has SDK_INSTALL +=
   libhello-dev but during the work he decides to install also libbye-dev using
   apt. I suggest to keep isar-apt configured unless there is a better solution
   for this use case. This also implies that we should keep both approaches --
   relocate and chroot -- usable.

3. relocate-sdk -r puts two slashes into the binaries. Also, strictly speaking,
   it doesn't restore the binary into the state it was before, since rpath was
   not set by default. Should we just remove rpath instead?

4. It is also possible to set rpath to a relative path (in combination with
   $ORIGIN). In that way, the same SDK would be usable with or without chroot
   -- the use case is e.g. #2.

5. I'd suggest to drop "recommended" and "fallback" from README.sdk.
   relocate-sdk is already listed as the first option. The rest is a matter of
   developers' preference. Or is there a specific reason to prefer one?

   E.g., I personally use chroot to avoid host environment leakage into the
   built stuff. I'd like to work on the host, but in a Debian way (think
   multiarch -- which IIUC currently doesn't support amd64-stretch on
   amd64-buster).

6. rpath and wrapping doesn't address all use cases.

   1. Shared libraries may use other shared libraries.

      E.g., ffmpeg fails to find libopenal.so.1 if
      usr/lib/x86_64-linux-gnu/libavdevice.so.58 is not patched.

   2. Binaries outside of bin are not patched, e.g. clang-format.

   3. Wrapping doesn't cover e.g. arm-linux-gnueabihf-gcc on qemuarm-buster.

   What is your vision on this? I think we will never cover all possible cases
   and should rather strive for a working subset -- which your patch provides.
   I also think this should be documented, because I assume that Yocto SDK is
   not buggy in this regard (manual usability due to -isystem and stuff left
   aside) and encountering such problems with the Isar SDK would be a bad
   surprise.

With kind regards,
Baurzhan.