Re: [RFC] using lightweight containers instead of chroot

[Jan Kiszka <jan.kiszka@siemens.com>]

On 12.07.21 14:29, Cedric Hombourger wrote:
> 
> On 7/12/2021 1:47 PM, Jan Kiszka wrote:
>> On 12.07.21 12:54, Helmut Grohne wrote:
>>> Hi Jan,
>>>
>>> On Mon, Jul 12, 2021 at 10:25:41AM +0200, Jan Kiszka wrote:
>>>> On 08.07.21 21:34, Helmut Grohne wrote:
>>>>> The reason to want DPKG_ROOT is to prepare the root filesystem for
>>>>> your
>>>>> embedded board. If that's not what you want to do, DPKG_ROOT is not
>>>>> your
>>>>> tool.
>>>> We want it for both the board and the build env. We have the same
>>>> issues
>>>> to solve there, means installing packages in unprivileged manner,
>>>> either
>>>> for target arch or the builder arch (cross and native builds need to be
>>>> supported). So I see DPKG_ROOT as a building block for both. In
>>>> addition, it would overcome qemu-user, which is speed gain.
>>> No. Let us for a moment assume that DPKG_ROOT would just work for all
>>> packages in Debian (and that is a far stretch really). Then you'd be
>>> able to install your Build-Depends into a directory without using
>>> chroot. But how do you build your package then? You need to chroot the
>>> dpkg-buildpackage call. So you are back to requiring chroot, at which
>>> point you can just install your whole build environment using chroot.
>>>
>>> DPKG_ROOT is the wrong tool for that job. The one thing that it fixes is
>>> requiring qemu for the embedded filesystem image. Cross builds already
>>> work entirely without qemu (including package installation).
>>>
>> We can't cross-build all packages, unfortunately. That's why we will
>> continue to require native installations for some packages'
>> buildchroots, just like we obviously do for the target rootfs. If you
>> can create and also augment (install deps) those without qemu, you gain
>> speed. Granted, those continue to require qemu for the actual build.
>> Which brings me back to still having to add namespace support to
>> binfmt_misc...
> 
> there is that:
> https://patchwork.criu.org/series/3855/
> 
> 
> I haven't checked if the author got any luck in getting his patchset
> accepted
> 

See https://lkml.org/lkml/2021/1/18/1267. Since then, it's on my long
backlog, but with rather low prio unfortunately.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux