From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6444767352800149504 X-Received: by 10.25.23.36 with SMTP id n36mr3199671lfi.39.1500969971974; Tue, 25 Jul 2017 01:06:11 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.77.87 with SMTP id a84ls382269ljb.48.gmail; Tue, 25 Jul 2017 01:06:11 -0700 (PDT) X-Received: by 10.46.87.65 with SMTP id r1mr3536104ljd.9.1500969971507; Tue, 25 Jul 2017 01:06:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500969971; cv=none; d=google.com; s=arc-20160816; b=Tws/fI4zGx9zcE6vEgOahp7sE3Rte/7V3ODlSuZg0nrnGEPS8Ot2qxzPmtbXbmXev+ cEq9J2M4S28MLUptu6hyu9Z2i62MdXUtyK1RqvvxROkpat8xLFTl3S68bGpETNZAKKU1 K5Ge9lohSby/wWGlUH0rwnZp+eh1ABXQbmumx2ydoyunM2KSNKXzBD5XhdZkIiLarLTP nu5Cds2Mj9LRYa+oyL9tZrtaTQtcy7wFMM87uRWo+e6Ku83B2snJd+5xUIKQL6AeCQBo YcQDl5gDNDddnx56ytc2X3pD7i+MgRJqsOAmepcaZdVcnLWpGDK09mDwOB6jZq8lbfWc k0uA== 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 :arc-authentication-results; bh=xDN55dLuVG4mojs0AUinxFJLoA/sDu+R/M+ITgHr+wE=; b=g46RawYHTOegxf+Uwjla9CzQpYAsTnWlwP+JgrEMMIPLzj6LyvCCz1BwBWnwdxam+W FSOc0qxjPsExifrcxdu922kOO0/7lkKlDnmgdyYcCQUAeGH0gMIAu9CEgBz1wiBOfPUJ Kb2GQvjqhIfEMx82fClYH2ETpcVnAvP2Z7XZFlTwnjzmN98bHgOyoPKfzcwXsS1MI4OY tndsq/0berre1wuYrcZDdCzcrjgxKAHOzfmGbbB6bdRlQzy9c9BsOW55bwdlk64Excpe 3Ii0stbpwzDRK2wTXYDCL4uvGwA+qXGRE7BjSkb8XB0hdDtUKg8F6lphji6WY8LF5YrC MYXA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 194.138.37.40 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id k68si2756828wmg.4.2017.07.25.01.06.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 01:06:11 -0700 (PDT) Received-SPF: neutral (google.com: 194.138.37.40 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 194.138.37.40 is neither permitted nor denied by best guess record for domain of claudius.heine.ext@siemens.com) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v6P869TQ025325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jul 2017 10:06:10 +0200 Received: from [139.25.68.223] (linux-ses-ext02.ppmd.siemens.net [139.25.68.223]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id v6P868D9019977; Tue, 25 Jul 2017 10:06:09 +0200 Subject: Re: [RFC] can we just extend openembedded to get Isar 2.0 To: "[ext] Jan Kiszka" , isar-users@googlegroups.com, Henning Schild , KOBAYASHI Yoshitake , Daniel Sangorrin , kazuhiro3.hayashi@toshiba.co.jp, asmirnov@ilbers.de, Claudius Heine References: <20170720103037.794aab2e@md1em3qc> <20170720230529.GB5040@yssyq.radix50.net> <844d35a9-6ffd-9a84-b324-21acec937eaf@siemens.com> <20170724225350.GC3612@yssyq.radix50.net> From: Claudius Heine Message-ID: <98c6b5a8-d428-5116-84fe-4342177c8af3@siemens.com> Date: Tue, 25 Jul 2017 10:06:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: rZNfYO3yxcM/ Hi, On 07/25/2017 08:08 AM, [ext] Jan Kiszka wrote: > On 2017-07-25 00:53, Baurzhan Ismagulov wrote: >> On Fri, Jul 21, 2017 at 09:31:05AM +0200, Jan Kiszka wrote: >>>>>> Claudius already suggested building custom .debs in Isar to solve that. >>>> >>>> Yes. we built them where the effort was justified. >>> >>> No, this is about making this feature available as library (class) so >>> that you write three lines of recipe and have a customization deb >>> package. That effort would be minimal for the user, and we only need to >>> solve this once properly. If OE-core cannot provide that, we will have >>> to implement it ourselves. >> >> Ah, I see. This is also on TODO. This is an example what we could do for Debian >> people, and this is what other tools don't provide. >> > > OK, great. Then the question is likely if we should extend or write a > separate tool for that or rather a bitbake recipe. Claudius was in favor > of a recipe, Henning found some tool in Debian. I am more in favor of a bbclass for this. Creating simple packages this way should be easy compared to expressing runtime and build dependencies to upstream packages or own packages created by a bitbake recipe and resolving and installing them into the build chroot beforehand. It would be great to get PACKAGES, RDEPENDS_${PN}, FILES_${PN}, etc. working again. I am not sure of the best way to do these kind of tasks in isar. To integrate isar into OE one way could be to have a recipe that fetches the packet index from the repository and populates the bitbake datastore with recipes or packages for every package in the repository at runtime. Or, if that is too hacky or does not scale well, hook into the 'DEPENDS' resolve mechansim and look into the debian package index there and generate recipes/packages into the datastore just for the requested packages. Also integrate use qemu + native debian toolchain as alternative cross compiler. This might need some additional finagling. >>>> You can copy the recipe from Isar, and OE will be able to multistrap. The >>>> problem is, you can't do anything useful with that afterwards due to the >>>> different base system and compiler. OE != Debian, just like Ubuntu != Debian. >>> >>> OK, that is a more concrete example to discuss: assumption of OE-core >>> about the compiler and the build environment (when we are building, the >>> exceptional case). >> >> Building is not an exceptional case, every product has its custom applications. >> > > Compared to the primarily goal, installing tons of prebuilt packages, > it's exceptional to Isar. That's what I meant. I agree that we do need > to build a handful of packages in most projects as well. Maybe I am captain obvious here, but should be possible to build static binaries with muslc in oe. Those would be independent of the toolchain. >> But while you are talking about percentage: What tools does OE provide? I'm >> aware of isar-init-build-env, bitbake, wic, and runqemu. What else is there? >> > > Classes, the secret source to glue all that together and make it > conveniently usable. > >> >> To summarize, what I hear: >> >> + Less effort to adjust tools for Debian in OE. Some of them might be a bit too hopeful and based on my implementation proposal: + Less intrusive change to the build system (bitbake + oe) -> Less work to keep it working with upstream -> Higher chance of beeing integrated into upstream -> Resolve many regressions of isar (compared to bitbake + oe) -> No need to reimplement most of the functionality (creating packages, images) -> Mostly compatible with oe recipes Cheers, Claudius