From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6607733288662466560 X-Received: by 2002:a19:4f05:: with SMTP id d5-v6mr83863lfb.11.1539275608345; Thu, 11 Oct 2018 09:33:28 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:6518:: with SMTP id z24-v6ls587177ljb.9.gmail; Thu, 11 Oct 2018 09:33:27 -0700 (PDT) X-Google-Smtp-Source: ACcGV60TsgXkMOVOGlDyS/wK/bkAGN+hntha18Xn2isE+uvhKk0WXufldRwe65T9rmxAWWkJFgsq X-Received: by 2002:a2e:9c03:: with SMTP id s3-v6mr88083lji.26.1539275607912; Thu, 11 Oct 2018 09:33:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539275607; cv=none; d=google.com; s=arc-20160816; b=wsyBjU+94UCbfsCOitjQn2jVUtBH2vxLuN69l7tM8QgaZ9jrBFFi80ABPpwsocXfTW UoYvAVLZdZk/CNQKGFc4d+Uj8Dae+ar7OM1kmBxq4bx8uH4Ut27l4JSabZD7vc/A77NE Fw2V//viQk/w4d2tH7EmnvTqKSjScG25m+QyeXm8RB/DKU7Q9fJBgyiVI9sxF2t2L9dt AdVa/hj4Ejgq+a7K2+p+KFXy+4pIk5CE7orad/h6It1c0r3io+TTHQFRLkQd4E97Ur5a 3bOWzaAzO+6rtdgwLYf3y+KxX/N8UmDUq0iO5uuaNNjnya0fyjSHqoowDaZIPZMe0uQ/ UQFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=RP6SWPFpg2MeWSBexSNBbPXeTorYT1WnbzOOTi4MhjA=; b=jSpanhyP+obud9Qu5uHZypMZfLzCM0noE7cU1wZPpTaU840wwO71MQh59Nnki4me4S NUUgT3P6B2UnAIZjD3SjK91mCElSP18Yv3tpa0Y/gWt1Bl9IYokCmwWH4pv8O5yQ/wA+ 1xX/JRRacNRJwYT9U5CGoGN+ZhgE77HwHYb+ZAZngrQaKuuXGmIRKOE3sbIU4mvJ9T9U CEsYIWq5yfjkqFHBGuFf+ZAmRv5GaOZLwIpYtCz3ddFnaDRpUE1Vq1P6OLARrivg9DTI Qzg7vbdn0voDK5zQbMKG0pcalXEl633HWaXdCP+QPyjLJPVwR/tKdkSbyS40yQGJ4jer zwgw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id m9-v6si1209552lfb.5.2018.10.11.09.33.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 09:33:27 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w9BGXOMt015591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Oct 2018 18:33:26 +0200 Received: from yssyq.m.ilbers.de (localhost [127.0.0.1]) by yssyq.m.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPS id w9BGXOZD001140 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Oct 2018 18:33:24 +0200 Received: (from ibr@localhost) by yssyq.m.ilbers.de (8.15.2/8.15.2/Submit) id w9BGXOxF001139 for isar-users@googlegroups.com; Thu, 11 Oct 2018 18:33:24 +0200 Date: Thu, 11 Oct 2018 18:33:24 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH 9/9] doc: Creation of local apt repo caching upstream Debian packages Message-ID: <20181011163324.GC14077@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <20181002121907.18476-1-mosipov@ilbers.de> <20181002121907.18476-10-mosipov@ilbers.de> <20181004090311.GA12890@yssyq.m.ilbers.de> <153874134595.16094.2206458362812855964@ardipi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153874134595.16094.2206458362812855964@ardipi> User-Agent: Mutt/1.10.1 (2018-07-13) X-TUID: d1wEOdIung9G On Fri, Oct 05, 2018 at 02:09:05PM +0200, Claudius Heine wrote: > Ok, but then the machanism should be designed that way so that this > feature can be enabled all the time, and the build should work on the first run > with this setting enabled as well. The mechanism doesn't preclude that. For this step, our goal is to have it under user's control, explicitly leaving the policy you'd like to have to the next steps. When we arrive there, we could decide whether ISAR_USE_CACHED_BASE_REPO should become the default, and whether we need it to be configurable. Till then, I'd really like to provide the choice for the user. > If you do 'bitbake -e ..' you see all used features in one variable > instead of searching for many different variables all over to find what > features are enabled. With a long enough list, it would end up being many different feature names all over. I guess we'd have to play with that when we implement something and see ourselves. For now, I don't see any decisive advantage. > I don't know if I understand you correctly here. I think you meant that > removing an entry from a variable is difficult. If that is the case, then > you could just do: > > ISAR_BUILD_FEATURE_remove = "use-cache" Yes, this is what I meant, thanks for the pointer. It does address the problem of removing and, as I've read, produces also better results when appending. With kind regards, Baurzhan.