Re: [PATCH v5 0/5] Debootstrap integration

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

On 2018-04-09 14:48, Baurzhan Ismagulov wrote:
> On Mon, Apr 09, 2018 at 12:50:56PM +0200, Jan Kiszka wrote:
>> what's the status of this series from upstream perspective now? Claudius
>> sent a documentation update. Any further requirements that need to be
>> fulfilled prior to this becoming ready for merge?
> 
> Sorry for the delay, I'm still investigating the following issues:
> 
> 1. CI fails with the series applied, and
> 
> 2. The series drops Pre-Depends support and daemon starting prevention.
> 
> 
> Regarding (1): As the series removes hostname setting, the image inherits the
> hostname of the build host. I.e., images generated on different build hosts
> have different hostnames. CI already checks the hostname and fails.
> 
> I'd suggest to restore at least the one-liner setting the hostname, possibly in
> {debian,raspbian}-configscript.sh.

This should go into an exemplary customization package in meta-isar.
Then you can test if that package is properly installed and has the
desired effect of setting the hostname.

> 
> 
> Regarding (2): The motivation for the old configscript.sh / setup.sh
> distinction was to support Pre-Depends. "Sometimes, unpacking one package
> requires that another package be first unpacked and configured. In this case,
> the depending package must specify this dependency in the Pre-Depends control
> field." [1].
> 
> Besides that, setup.sh prevented daemons from being started during the
> configuration, which they otherwise are.
> 
> The series happens to work with Isar's minimal set of packages. ATM, I'm not
> sure about the implications for real projects with more packages. What should
> we do with this?

We either need concrete use cases for both aspects. Can you provide
examples that no longer work as expected or have other limitations now?
Otherwise, I would postpone these topics until the use cases show up.
Maybe that will happen when exposing the patch series to a broader
audience, but so far I heard nothing in this direction from our existing
users.

> 
> (I still think that in the end, we'll need more features than debootstrap
> provides today, but that's a different story).
> 
> 
> In general, I'm willing to move forward quickly. That said, I'd also like to
> understand issues and have consensus when which issues are going to be
> addressed. Till now, master has been the stable branch. Maybe we should
> introduce an additional staging branch other than next. What do you think?
> 

Well, the way master and next are maintained already differs a bit from
common pattern. Master is keep untouched much longer than usual, and
next is only updated after integration in Alex branches matured. The
more branches you have, the harder it gets for contributors to pick the
right one to develop against. If master is updated too infrequently, you
cannot use that. If next does not contain enough integration material,
you are easily forced to look for the latest staging branch to ensure
your patches still apply and work the other day.

So I would recommend to update master more frequently and merge patches
into next as soon as no review comments are pending any more. If you
really do not like to run CI over next (which may enforce some more
rebases of that branch - if only CI reveals issues), have a short-living
CI branch for that purpose, and only that.

Regards,
Jan

> 
> References:
> 
> 1. https://www.debian.org/doc/debian-policy/
> 
> 
> With kind regards,
> Baurzhan.
>