From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7023151278367703040 X-Received: by 2002:ac2:54a6:: with SMTP id w6mr25491220lfk.277.1635274697887; Tue, 26 Oct 2021 11:58:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:1a4:: with SMTP id c4ls3715987ljn.1.gmail; Tue, 26 Oct 2021 11:58:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhcXyHWo9obX8cm6YBh/PXdus+fJHoEaO6+fOzaKrtUEQAxdeVrEkZmVQKIS8NWA4QSBT3 X-Received: by 2002:a05:651c:1b8:: with SMTP id c24mr28764990ljn.436.1635274696875; Tue, 26 Oct 2021 11:58:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635274696; cv=none; d=google.com; s=arc-20160816; b=yT9dSpfwtZzU2MVut7Tva+AosM8bx5cCBp/8YM5rRbmXEQp8dLzMzmJz5nuLaruLX4 gC6B20ADP0uGRLD9xOzggZthMVfsvBt3Xd1EKteEr/Ttj7OZkG7To1Dng5ddgb8RJWVN 2AQaaI0oOWfs9skZVXEvEkNWDqIZ0rXegUB582Y+pn4terQU0i+SXoHRqdn+OMS/8vPQ aoeoCESrHN1D6pYKO499O1VYejgsZQPoY9aJXPnbelrCsOW2nG6W0ePO9AtczpiSgtif I3KvLX9gFxwi0MAGVG8sXqXGXgWVswVyz2yzKVCEkZnH+g6zy1oYg8WfHLELBneDSJ45 FToA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:subject:in-reply-to :message-id:cc:to:from:date:dkim-signature; bh=9n8ZtEezbxiFeLYFKsORL1MFXMcxYnf//oyR4qY7hN4=; b=eV8fMlSOJf/KPcojWqZskCWUiZ8eYIBi3iWCPaI0SX7tbX0RHgN0hAhrxX/3yJzWYT oyLiHsePd3Xe77PvP8MQJ78Tgbe8cU5/Of5Qq+/SpJs9QJ9nuhPeXsbInbMxvyzVKxoQ 70QPova50vFQyhkckRNQcYcZib/UWpRuQxCN3pJn9FndCxeF+w3VqEMBgYl148C8azRZ c8SngCxh2arMkDETNH3j40DplqS47bHx1XFdQCstI2/T7SrSxIwxe7L/g6rXhRKFBNcY NygbdNh6t7XCfIqSCzI5GiUR7TeCutJtRCKl/3n2mzK/JJyov2JEUq97YItXsAG1zLxs NLbA== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@free.fr header.s=smtp-20201208 header.b="M/VlR2Mu"; spf=pass (google.com: domain of ydirson@free.fr designates 212.27.42.1 as permitted sender) smtp.mailfrom=ydirson@free.fr; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=free.fr Return-Path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr. [212.27.42.1]) by gmr-mx.google.com with ESMTPS id m21si968604ljp.2.2021.10.26.11.58.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Oct 2021 11:58:16 -0700 (PDT) Received-SPF: pass (google.com: domain of ydirson@free.fr designates 212.27.42.1 as permitted sender) client-ip=212.27.42.1; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@free.fr header.s=smtp-20201208 header.b="M/VlR2Mu"; spf=pass (google.com: domain of ydirson@free.fr designates 212.27.42.1 as permitted sender) smtp.mailfrom=ydirson@free.fr; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=free.fr Received: from zimbra39-e7.priv.proxad.net (unknown [172.20.243.189]) by smtp1-g21.free.fr (Postfix) with ESMTP id 848A6B004D5; Tue, 26 Oct 2021 20:58:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1635274696; bh=YpZBROcAk3Ya6Ff5UIWiP8dn4XWtEL2ugpN9o3N7L0k=; h=Date:From:To:Cc:In-Reply-To:Subject:From; b=M/VlR2Mu2u/Y3UNb+yMAYb9MW4rUybS2UDxEV8GZ8uU5emVcZq5kq0iGI3lYukt4a ccfVA3Nx+tYBi0fuZGydI8I0VLAM+ooYoZuegA6itU+a4Ws+1xZ9w22g+CwraXL5jf 1jzOaqDYGMzJw3kpJilmK6myKFNKvw1VRHj+B3i5wMRvtbyhEXmFbSQz6FhUu++3tO KeK0nhqLveV3IJ5Shmr8rdhRC9RdAFdh/b1jl+p3ziDsZ/M9n4J6nRSar0VxwpaubJ s/GfQJb2hj4gVz0QCQQMC+kwVeXd7bp1v3pwfRvqEBqhXztjkLeRW/S+Pys1tR7AI6 TItAD8C+2i2ug== Date: Tue, 26 Oct 2021 20:58:16 +0200 (CEST) From: ydirson@free.fr To: Henning Schild , Anton Mikanovich Cc: isar-users@googlegroups.com Message-ID: <1737723933.1347608081.1635274696462.JavaMail.root@zimbra39-e7> In-Reply-To: <20211026094452.33fccc15@md1za8fc.ad001.siemens.net> Subject: Re: isar-bootstrap MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [88.120.44.86] X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Linux)/7.2.0-GA2598) X-Authenticated-User: ydirson@free.fr X-TUID: ujKdsmY6ZueR Hi, Anton wrote: > > 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. Cool :) Henning wrote: > This was already fixed by `[PATCH v2] isar-bootstrap: Fix SRC_URI > inclusion` and will be merged into next soon. > > 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. At first sight I don't find this last part too problematic, this looks like the standard double source/binary namespace, and DEBIAN_DEPENDS rather looks like a Yocto RDEPENDS (though processed), and DEPENDS a Debian Build-Depends. (indeed Yocto packaging does generate Depends from RDEPENDS when building a deb or ipk) > No need to > comment on a possible idea, it has been tried and is more complex > than i made it look. I guess this refers to the double-downloader problem, I had my share of such things some time ago [0] (and finally found a rather acceptable solution based on (IIRC) the meta-rust approach). I'd be interested to learn about the approaches you tried. > That said you can not see everything in our code, the files placed > carefully will be used by debootstrap and later by apt. Sure, such things do not lay themselves on (e)paper in one day, and that can make them more difficult for newcomers to see all the implications of a given construct - and also makes it easy to break things. > 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) Yes, I realized this and was not suggesting to drop them and use SRC_URI instead (although the idea did cross my mind ;). This remark was purely from the bitbake side, and I realized thinking about it later that some assumptions of mine may have been wrong, I'll have to check this later. > > 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 OK I see. > > > > > 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. Yes, I had to refrain from bringing too many subjects already :) > 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. Yes, though I will need more time to get a full picture. [0] https://patchwork.openembedded.org/patch/178697/ Best regards, -- Yann