From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7023151278367703040 X-Received: by 2002:a05:6000:1b09:: with SMTP id f9mr12398780wrz.412.1635234298289; Tue, 26 Oct 2021 00:44:58 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6b08:: with SMTP id v8ls4453424wrw.3.gmail; Tue, 26 Oct 2021 00:44:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZKQqUQok31BgldO/xl2rnwYgqDvlGKubnTl04BnG2QkTNg1QH7I3dLgh62H+TXVN6df0f X-Received: by 2002:adf:c00d:: with SMTP id z13mr29040172wre.299.1635234297274; Tue, 26 Oct 2021 00:44:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635234297; cv=none; d=google.com; s=arc-20160816; b=lb/oDaLEhogNzOW1WxmPsEfFXRRow/UYnpm+l1YFm7NlV5rgZjNArFYQ3+yVYriLvG FoELFFIhQcsGA0BMV0a3z0q+/eg0MUtWj4Ks1GozK26Earu8v1dOsXOvWJamZhfTU6sZ RkafXXgx/qfUE63Y9HHQ7asipQog0uePR7h8DBm//Fw6JDsno2lACKh+/oAZwGV+vvue 2DBDc0c6/7K4HRs1iNVVAZ4h4wSEv6Usnr25r/0M+O8sIyEzLm6wG28pZa28pmB1bPEu MLHjayHwIn+H/Pni19EsG1tVklYUxUQBUNVy7sEJENRGBheI383N02cjnxT/iJXxesZ/ bI9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=c8l57syA30n7TlMa62BfRZo6SSIP1LVqsKXvPk6CSJA=; b=jcdT+Xs05I9fVyoCw6/Z7FL2E+tumOCk4cEbK8gR+jZWvobwi1fZXlbBbPTNXoiS08 DShmhUflNh9T7csWWXhwp4B0wlfUR2qeAc1bbaJBLw/yl5Q1nSfMtDbSdpsZPrlv5fPT z9rY3BEeJdijxGMO/y140oJtymKZB3uIKeRS2ztZ/zrZ74cfN8MvEERWl9u262AiACIn gZa+64owoAPc8tLTtc1H2XwmSpMLLYNSj/GnMuOs+/2NaO17IagzznN82XKxhJHr2sDe EHCxdde3R6nyQqoJlnP5mSN/BkhWhquHCQ7EnHcr3u6+2k3XVp20odBQmji901NuDcTM SMIw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id a10si1285663wmb.0.2021.10.26.00.44.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Oct 2021 00:44:57 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 19Q7iu7b010619 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Oct 2021 09:44:56 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.32.154]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 19Q7iuCE023711; Tue, 26 Oct 2021 09:44:56 +0200 Date: Tue, 26 Oct 2021 09:44:52 +0200 From: Henning Schild To: ydirson@free.fr Cc: isar-users@googlegroups.com Subject: Re: isar-bootstrap Message-ID: <20211026094452.33fccc15@md1za8fc.ad001.siemens.net> In-Reply-To: <853542706.1343708285.1635204831683.JavaMail.root@zimbra39-e7> References: <1723895297.1343656873.1635201406531.JavaMail.root@zimbra39-e7> <853542706.1343708285.1635204831683.JavaMail.root@zimbra39-e7> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: Nlk7pUZQ651Z 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,