Re: isar-bootstrap

[Henning Schild <henning.schild@siemens.com>]

Hi,

Am Tue, 26 Oct 2021 01:33:51 +0200 (CEST)
schrieb ydirson@free.fr:

> Hello,
> 
> While reading the isar-bootstrap recipe to get the gist of it, I
> stumbled on what looks like just a typo, but could possibly be more
> than that:
> 
> I was trying to get a grasp on DISTRO_APT_SOURCES handling, and
> noticed a spurious match for "distro_apt_sources" in
> DISTRO_APT_PREFERENCES handling. While this possibly was meant to
> read "distro_apt_preferences" instead,

Indeed, that looks weird.
https://github.com/ilbers/isar/blob/ceb7e21154fc4862f704bb5c7739e87a26db6eb3/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc#L67

> it raises the question of
> whether it is useful to add all of this to SRC_URI if not adding it
> did not cause any problem (it does not appear to be used by any conf
> in isar itself, but I guess it is/has been used in downstream layers).
> 
> This brought me to where this gets used (both _SOURCES and
> _PREFERENCES in fact), ie. do_apt_config_prepare: the whole point of
> SRC_URI is to direct the fetcher to download/copy source files into
> $WORKDIR, and then later tasks (unpack/patch in OE) take files from
> there.  But here, $WORKDIR is not used, and instead aggregate_files()
> uses resolve_file() on them.  At first sight this seems to break the
> bitbake abstractions (and seems unnecessarily complicated at the same
> time).  Am I missing something, or is it worth for me to try patching
> ?

Not sure i get your point. In general we have to deal with two worlds
in Isar. There is the debian-world and the bitbake world and they are
not too tightly integrated at some points.
Meaning we have debian fetching stuff and bitbake fetching stuff. We
have two namespace for packages which leads to weird statements like

# comma-sep
DEBIAN_DEPENDS = "debian-binary-package-a, debian-binary-package-b"
# space-sep
DEPENDS = "recipe-for-binpkg-a recipe-for-binpkg-b"

That two world can not be easily resolved and is found in several
places, the one i pointed out being maybe the nasties one. No need to
comment on a possible idea, it has been tried and is more complex than
i made it look.

That said you can not see everything in our code, the files placed
carefully will be used by debootstrap and later by apt.

And the two variables are lists of files which are meant to be
customizeable. That way you can switch to another mirror, add more
repos (ppa in ubunut speach) and configure what to take from where or
what to possibly pin (prefs) 

> On a related note, I assume that aggregate_files() was meant to
> support distro versions predating preferences.d/ and sources.list.d/
> - would it be correct to use the latter instead to simply things
> further ?  Most recent is preferences.d/, released with 0.7.22 in
> 2009, and stretch which seems to be the oldest supported distro has
> 1.4.

I do not know, maybe also to be able to delete things again after the
build. Because you want other configuration at build-time than you want
on product delivery. i.e. build against a "frozen" mirror but deliver
with a public mirror as update source
 
> 
> The chroot-setup.sh script there also seems to do things that are
> already handled by the debootstrap (policy.d and start-stop-daemon),
> except for the upstart support.  Even if someone still uses upstart
> (which has not been developped since 2014), probably the rest could
> be omitted ?
> 

Thanks for the feedback. But i guess it might be a little much mixed up
in one email. So i mainly answered to give you more information, not
because i want to go and write patches.
But maybe you at some point might want to.

regards,
Henning
 
> Best regards,