From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6467463440282681344 X-Received: by 10.28.128.211 with SMTP id b202mr1828933wmd.5.1507138495123; Wed, 04 Oct 2017 10:34:55 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.93.130 with SMTP id r124ls3457308wmb.12.gmail; Wed, 04 Oct 2017 10:34:54 -0700 (PDT) X-Google-Smtp-Source: AOwi7QB5WtWsJq6VvriVv9HGMFOD0LieMemsbdK2v3PMal8LX8wLI+KHk9vzkRwLGm1tCCEbUmHZ X-Received: by 10.28.135.132 with SMTP id j126mr2911225wmd.0.1507138494787; Wed, 04 Oct 2017 10:34:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507138494; cv=none; d=google.com; s=arc-20160816; b=wg47MFfQZcg8lUpnJ9HvoqMdMNDTJLBZd5NCevRs2kFzdE5idPp9dOpwlwFDgQky7q KQL0x1/ba8Sda9VoPhvh7YDkpuXVsVNXfjwyb07dHMpvI/cep24VNRud3bPpOn+dCSQR JsjZTMna7ok4o77txUhqLAdnK9l3f75Hn4dBSO2uuSSvnIw4supWiqcvs9f6g2FvyY/X MHtHU7tfdVOLljTgadfk0L+Xro2BEFGO2J9z3oOjjfqhFMpmCTxiGddkZPHB1B5LhbJz dyMIGctYCLynHARWJpxmWCMSsH2TcieWo4d8bzR6e16bBlhka9rSFVyBbvO/anJTeEN7 FEKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:date:to:from:subject:message-id :arc-authentication-results; bh=CWiQLeiMv7tQORZX+0N4DZO6WNad5VcVZnzRfqI39q8=; b=YJsynFvo57vng4rHPZeZxBNTLOjq5dZwDbLq9XFSkPBucX4K8bsj7blg4n278imm0Q S9TWWNowdfCqNusm0EUh1VbFC6Fizr23hvdJbawahQ+fKJhyOtWaJ8FUvy5kV5ydNx8z /HPxKtO3uxpA3N/bPvBOSL6BiCFPRKpLpU3BXFeWxnc6yQMXcpkDtjwnbXO49qXydYws 5IwqwMv53mW4LCvdeTi2f/eoMF7jYuGZQVcXKSsD3sOWK9QhGHuuOEf0wBn2uwMOap0K bxz93slK9A99F0ENA6VJXtPTxkYP8ncUM+MVKm83g5GIhAwhquV+E7Ce0WIpcObJBQFZ huCg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.10]) by gmr-mx.google.com with ESMTPS id 196si1169358wmk.4.2017.10.04.10.34.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 10:34:54 -0700 (PDT) Received-SPF: neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.10; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3y6jhZ3Fckz1qx3R; Wed, 4 Oct 2017 19:34:54 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3y6jhZ2wS2z1qr44; Wed, 4 Oct 2017 19:34:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id DOYx_ICu95KQ; Wed, 4 Oct 2017 19:34:53 +0200 (CEST) X-Auth-Info: +H14Vj9+TGPCvkdNr6Dhs9FMv95PRGiP/tA5EPFYGC4= Received: from orrorin.lan (dslb-088-072-242-208.088.072.pools.vodafone-ip.de [88.72.242.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Wed, 4 Oct 2017 19:34:53 +0200 (CEST) Message-ID: <1507138484.6743.54.camel@denx.de> Subject: Re: [PATCH v4 0/4] Basic binary cache implementation From: Claudius Heine To: Alexander Smirnov , Jan Kiszka , "[ext] Claudius Heine" , isar-users@googlegroups.com Date: Wed, 04 Oct 2017 19:34:44 +0200 In-Reply-To: <2e00bbc9-9823-850e-9451-9d66350713b5@ilbers.de> References: <20171002154531.4930-1-asmirnov@ilbers.de> <2e00bbc9-9823-850e-9451-9d66350713b5@ilbers.de> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-t+m7yvtyhDXBxtUV2EPH" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 X-TUID: Bo1pDseX8JXP --=-t+m7yvtyhDXBxtUV2EPH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, On Wed, 2017-10-04 at 17:29 +0300, Alexander Smirnov wrote: > On 10/04/2017 02:57 PM, Jan Kiszka wrote: > > On 2017-10-04 10:32, [ext] Claudius Heine wrote: > > > Hi, > > >=20 > > > On 10/0 '2/2017 05:45 PM, Alexander Smirnov wrote: > > > > Hello everybody, > > > >=20 > > > > this series introduces basic binary caching for Isar. > > > >=20 > > > > There is a new layer: meta-isar-bin which is intended to be the > > > > binary > > > > cache. All the packages that are built in Isar are stored in > > > > this > > > > cache using reprepro. > > > >=20 > > > > Having the separate layer makes possible to manage this cache > > > > separately > > > > from the Isar build tree. So once you have built your packages, > > > > you could > > > > re-use this cache for further builds. > > >=20 > > > We still have to talk about your requirement for the cache to be > > > sharable and your resulting implementation of it as a meta layer. > > >=20 > > > Since I still don't see the benefit of a sharable cache and think > > > that > > > putting binary packages into some kind of strange meta layer is > > > not the > > > right solution and could potentially create more problems that is > > > solves > > > because its very much in conflict with the fundamental idea of a > > > meta > > > layer. >=20 > The last statement is a bit strange for me. The idea of meta layers > is=20 > to split software stack into logical layers that could be=20 > enabled/disabled on demand. Having binaries or recipes doesn't > matter=20 > here, it's just the way how software is provided to build. >=20 > >=20 > > Indeed, state like this (disclaimer: i didn't look into all > > details), it > > sounds like a weird architecture to me as well. Thinking of an > > artifact > > cache, I would rather expect something like OE's sstate that one > > may > > preserve across builds, share between devs, or whatever. If it's > > there, > > the build system consults it, if not, it rebuilds. But sstate is > > not a > > layer, for some good reasons. > >=20 >=20 > Let me again summarize major points here. Isar is the build system=20 > designed to work with binary packages. That's the key feature of > this=20 > product and main difference from OE-like systems. The Isar > architecture=20 > assumes to be designed around binary packages, what provides > absolutely=20 > different approach how binary images could be generated using > bitbake. >=20 > According to the Claudius's vision, that everything should always be=20 > built from sources - Isar is not the best option here, Yocto and OE > are=20 > much better, because they were initially designed for this work.=20 > Attempts to apply OE design and philosophy to Isar could have > negative=20 > impact and limit possible ways to implement custom features, because > OE=20 > wasn't designed for this features. > Also I wonder why we are able to use binary Debian packages, while > the=20 > rest of software should be built from sources. You are still not understanding me. I never said you have to build every package from source code in isar. Instead I mean that you have to build the root filesystem / images / packages ... ( every output of isar) from all the available input of isar (upstream debian repositories, meta-layers, source code repositories, etc.). If you create intermediate products in the form of caches, then that is ok. But if you put those intermediate products into repositories and begin to distribute them, then this causes problems as I described before. Distributing intermediate products is always a bad idea and systems should not be designed with this in mind or even advertise it. That has nothing to do with 'OE' or 'Debian' or any other System, its just general software developing and maintenance rules. It is ok to to this occasionally on a case by case basis, but it should not be a requirement or even an advertised feature. > ... In the rest of your email or this thread I still don't see any reason why sharing caches is necessary. Building the output from the input is fine once to fill the caches. Just to be sure that you are in fact able to build the output from the input. And I don't get why this is bad in your opinion. I get that we can trust that Debian can build their packages from their sources, so we don't need to test that, but at least test if we can still build our own packages in isar. Claudius --=20 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 PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153 Keyserver: hkp://pool.sks-keyservers.net --=-t+m7yvtyhDXBxtUV2EPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAlnVG7QACgkQEXPLGZgI sVMdNQ/+KZCR8sNSC/3tFmVJ/xV31Xnp5CcoRgBAz0yM075RTFjwIijQG2KW1v6p gB6q9UPWKZUqi8/ecu9P5+wapZ0KxfNW/cR+f5thw2XMyzxUWdNSzgod71nQ5/aI Yb5I8E1Vjl6PBoBmUUti1jCssWwVYif/zSIUjWbOFhU2NLRChGVlbJ6oX0vD7/va hLTX3xtPjMDrspwcWSQ6Iu4pnU25/JaflezbX3qvYZRxGPzc/YOOFEUZDYiusp3V fSasDSNRIgWPx5+mIriPsLkwPz5VyVIRG6Bg7Y3fZxnn7g5Mu6YSNcVy3DjQhbHn Bk3T1p/gNmkJViBjGB0y1B2aO69WwYBufOycwoLE5Xvfno9+i24Fc4qM8RZb2u2y MUnY8tCQ3DarqtxS0R2TnWV7UqPTjy5q6l5gdoosI3HrgHQgegGCx3moPfQNwCah WG8wxPNR3DItDSMTLN2EFT07en2XKyvKlGZzmxAK569zRDW59HvCQp6bnM2JmhB3 jF4Rh5gBB+5B1WZddOteefRJS8Nw8CvBDMHx6lc1nIL6w4EnaJm9mHUs1OY12idY Qfkn1/XE72IQPODUQ8jm4h3E0yXMM37cKsOF4+6f66c2T7FUgubUGJJz7WaynZdg mGjauJR/R4+i3Kjp6E7UNQupiA55ZKChGMUHFiekmyDVxNDVWbQ= =Gng+ -----END PGP SIGNATURE----- --=-t+m7yvtyhDXBxtUV2EPH--