From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6698318213090902016 X-Received: by 2002:a50:addc:: with SMTP id b28mr67546247edd.174.1561376921572; Mon, 24 Jun 2019 04:48:41 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:7f15:: with SMTP id d21ls3840825ejr.1.gmail; Mon, 24 Jun 2019 04:48:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwhgy6tdFaeJTcEG3PFjG2seK1paV3pEaaGXpJSL1sBP+2eYEnMnsElS6tj0T0ijL7xKpOd X-Received: by 2002:a17:906:24c2:: with SMTP id f2mr9568616ejb.233.1561376921187; Mon, 24 Jun 2019 04:48:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561376921; cv=none; d=google.com; s=arc-20160816; b=W9ZD9Kgn7/E5OBTOn6yLnaTRjZEzuZBBY0mwKFQSNDI8Vkb8xoUM2HqzHq7mYtJwA1 E7eHhs6mspCUQBzXoK0MVhFyVfhtMd7EPwRGw+qavbhU7FxoKu194vGMg/pNPY2qtnAQ uxjGOQr9nlMR0P9aI7C1ny12swJ007Of+EQS1oSmSUIGlKZgMOh6TiSQSl/quKnwvn/l WiMLpB4uq4MVK+HzBE5lvjyEnTOn8ObKW0hYrEF+fabN4RPN0yWIdTWySUCtk3f/+lAp +i6xJOGzek+RG3LNlh6g4zDz8jN8UfyjYO0WplJzxYZpWZ8R0gSkI8aQYDwkTwyMO2Ai 8twA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=MMFIYqAoTOInn3HJ4BYvt+a7aYbhcZ4iGcOVHmQCEsE=; b=EcyVFDKjCROJ9OgcFaAfhLx8oYrngTbuH1XA7Rzi0Zhbj/MFU6m3St5qtzpHIPzNgd tFkkOTZai1/qxSxQbeZojk3YU6Bdch5e0a5EycypLYUtYfsFIMftxaHsv8Oh7ckJM6WF gmAStqz8XLSFTWTHYxRF71b02COXCeUljSo6o6GDzfT7KiiS2WB22HDPZiYavmZ1XK/Y VfWYU+THlLgtVfQFSPdrrfLgewBJpkvSf7DMb4kpYqC80a74bX8Iw9Zoyrpf5prObR9X fKN93Qp0KczEfbmJ9BTfSxH09v4epZcrDdw2FUVgh6Hzhug6oGSyrp7NnPWz9x6YEFSO yGJw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id t15si539473ejq.1.2019.06.24.04.48.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 04:48:41 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x5OBmelA011486 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 24 Jun 2019 13:48:40 +0200 Received: from [139.25.69.208] (linux-ses-ext02.ppmd.siemens.net [139.25.69.208]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x5OBmeLG011044 for ; Mon, 24 Jun 2019 13:48:40 +0200 Subject: Re: TODOs To: isar-users References: <9345ebb3-983b-06b5-0a32-572a595d9d5c@siemens.com> <20190619155718.GZ3977@yssyq.m.ilbers.de> From: Claudius Heine Message-ID: <28fe87a0-1aaa-9f91-2bd0-62bfd8adc89f@siemens.com> Date: Mon, 24 Jun 2019 13:48:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190619155718.GZ3977@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: FDlzz7K5rvLQ Hi Baurzahn, On 19/06/2019 17.57, Baurzhan Ismagulov wrote: > Hello Claudius, > > thanks for sharing. > > On Mon, Jun 03, 2019 at 04:55:39PM +0200, Claudius Heine wrote: >> here is a list of TODOs for isar that I gathered: >> >> - WIC_IMAGER_DEPENDS should be IMAGER_DEPENDS instead > > Is it a new var, or do you by chance mean WIC_IMAGER_INSTALL and > IMAGER_INSTALL? Yes, you are right I meant *IMAGER_INSTALL. > > >> - IMAGE_INSTALL, IMAGE_PREINSTALL, DEPENDS refactoring so that it is >> possible to provide recipes that produce multiple packages. Currently all >> entries in IMAGE_INSTALL are added to DEPENDS, but DEPENDS should only >> contain recipe names and IMAGE_INSTALL only package names. > > This is tightly coupled with the subject of handling Debian packages with > bitbake, which we have been experimenting with in meta-eid. We had started with > the dependencies. One limitation is that bitbake parses all recipes, then > builds the dependency tree. Debian packages may be local or remote, so they > have to be fetched before the dependency tree is built. You would only need the Packages files from the repos in order to figure out the dependencies. > > For now, the workaround is to duplicate Build-Depends: in DEPENDS. That is not really possible since we don't have recipes for every debian packages. DEPENDS and Build-Depends are different. > > Do I understand your use case correctly, you have a.bb producing aa.deb and > ab.deb. You want to have IMAGE_INSTALL += "ab" instead of "a", do you? If yes, > can this be workarounded with PROVIDES = "aa ab"? Probably, but I don't know how things like 'virtual/kernel' could be handled then. That would possible required all debian packages of the kernel to also contain a 'Provides: virtual/kernel' or similar. If we do that, I see the risk that because we bind recipe names and provides and debian package name and provides a bit to tightly together that things will not work out and end up with corner cases we cannot model. > As I see it, the final > solution without duplication would require solving Debian package handling in > some way. Do you mean by that the import from apt repositories into bitbake data-store and export from bitbake data-store to control files? >> - base-apt refactoring/redesign: >> - multiple distros/codenames in one base-apt repo. base-apt repos should >> be build specific not specific to distros/codenames. > > I see that this is desirable for certain use cases. > That said, it might also be > a matter of downstream policy, so that either choice is poorly suited for some > other downstreams. Ideally, I'd like to have it configurable. Well in order to allow both ways, the code needs to be changed anyway. I did thought about it some more now and I do see reasons to have it distro/codename and build specific for different use-cases and it might even be ok to leave it as distro/codename specific per default. At least I currently don't remember the reasons I thought of when writing that todo list. >> - no manual switch via `ISAR_USE_CACHED_REPO`. The cache should be build >> and used at every build > > This can be enabled downstream. This is also a matter of policy: Some projects > always work with the latest stuff, some make snapshots. The ability to turn it > off is useful as a reference if anything breaks. Well IMO the cache should be used per default. If someone wants to update a image after the initial creation, then this should be done explicitly with full knowledge. > > >> - redesign fstab generation: >> - make it more flexible >> - usable with or without wic and init system independent >> - isar-bootstrap refactoring: >> - remove duplicate code >> - split up big functions to allow >> - inc file should be class >> - separate host/target bootstrap settings >> - host/target/build nomenclature fix > > I agree that the inconsistencies exist. The main reason is that compiler people > have to name it differently from the 99% of application developers who > intuitively understand the right thing from "host" and "target". So I'm still > not sure whether the change is worth it. As I mentioned in previous discussions we could avoid this issue altogether by calling what is currently called 'host' -> 'native' and remove the word 'target' where possible. 'DISTRO' and 'DISTRO_ARCH' will still be called the same and 'HOST_DISTRO' and 'HOST_ARCH' will be 'NATIVE_DISTRO' and 'NATIVE_ARCH' for instance. Or 'buildchroot' and 'buildchroot-native'. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de