RE: multistrap support

[<kazuhiro3.hayashi@toshiba.co.jp>]

Hi Baurzhan,

> -----Original Message-----
> From: meta-eid@googlegroups.com [mailto:meta-eid@googlegroups.com] On
> Behalf Of Baurzhan Ismagulov
> Sent: Thursday, February 14, 2019 4:24 PM
> To: isar-users@googlegroups.com
> Cc: wookey@wookware.org; meta-eid@googlegroups.com
> Subject: Re: [meta-eid] multistrap support
> 
> On Wed, Feb 13, 2019 at 01:14:57PM +0000, kazuhiro...@toshiba.co.jp wrote:
> > I would like to know if isar still has some plans to use multistrap again
> > (or similar existing tools if exists) to generate target images.
> >
> > Multistrap for isar-image-base has been removed by the following commit:
> > https://github.com/ilbers/isar/commit/19a314559178f7afd93ce3dafe8c8647ca6c8884
> > and replaced by setup_root_file_system() in isar-bootstrap-helper.bbclass,
> > which seems to use (pre-built?) isar-bootstrap-$ROOTFS_DISTRO-$ROOTFS_ARCH
> > as the base tree instead of running the debootstrap process.
> >
> > I guess that the main purposes of quitting multistrap is that
> > there is no big update for a few years (though the last update is 2.2.10 on Nov. 2018)
> > Are there any other reasons?
> > (Some bugs difficult to be fixed, mismatches with isar specification, etc.)
> >
> > The current isar-bootstrap based approach would work fine for isar system,
> > but in that case, it might be difficult to share efforts for
> > developing and maintaining the functionality with non isar users.
> > I'm just interested in the future plan of isar.
> 
> Neil told us that he doesn't maintain multistrap anymore. We also encountered
> issues (e.g., https://github.com/ilbers/isar/issues/16). For me personally,
> Perl is an obstacle (I go through Perl tutorials every couple of years :) ). So
> switching to debootstrap was easier at the time.

Thanks. At the moment, I think that the debootstrap based approach might be safer
using than multistrap from future maintenance point of view.

> 
> That is not to say that debootstrap is the tool we want to have. The focus of
> debootstrap is to create Debian rootfss on Debian and non-Debian systems with
> the least possible dependencies. Given that, it is developed in shell, which is
> also not maintainable.
> 
> In the long run, we'll need more and more introspection into apt & Co. for more
> advanced features. One way could be multistrap re-implementation in Python, as
> suggested by Wookey. ELBE has good experiences with libapt. aptly also promises
> some features we would like to use (though probably not multistrapping OOTB).

I'm not sure how the multistrap re-implementation is demanded in Debian community,
though we are interested in that. In this discussion, I recognized that
there are several approaches to bootstrap Debian images including customized
'essential' packages. For examples,

1. multistrap (Debian mirror + Custom repos)
2. debootstrap (Debian mirror) + apt (Custom repos)
3. debootstrap (Merged repo = Debian mirror + Custom repos)
and more...?

aptly probably helps creating the merged repo in 3 as well as snapshotting
and maintaining required repos effectively, I should look at this.

> 
> Bootstrapping hybrid repos is also a useful use case. It can be achieved by
> making the "secondary" distribution upgradable from Debian, but if one has a
> lot of customized packages, using multistrap would require less effort and be
> less error-prone as well. In Isar, we try to stay away from massive
> modifications, but there are projects ending up tuning significant parts of
> Debian.

Thank you for telling the current situation in Isar.
IIUC, this is comparison of the 1 and 3 above.
I agree that multistrap effectively works in case where there are a lot of
customized packages.

> 
> The specific tools don't have to be mutually exclusive; Python offers enough
> polymorphism to include both as plugins (bitbake support has to be checked).
> With quite diverse requirements and opinions we already have today, we'll need
> pluggability, be it for multistrap or other features; the earlier we start
> playing with it, the better. For me, it is the question of enough itch rather
> than resources.
> 
> For your specific use case, I don't see a problem using multistrap for meta-eid
> till we have a better alternative.

I agree.
I've just support two solutions (1)multistrap and (2)debootstrap+apt in
debian-image.bb (Very simple example of the image generator)
https://github.com/eid-project/meta-eid/blob/master/recipes-image/debian-image/debian-image.bb

Kind regards,
Kazu