Re: [OE-core] [PATCH] base/patch: Disable network for unpack/patch/configure/compile/install

[Konrad Weihmann <kweihmann@outlook.com>]

On 23.12.21 15:52, Andreas Müller wrote:
> On Thu, Dec 23, 2021 at 2:19 PM Konrad Weihmann <kweihmann@outlook.com> wrote:
>>
>>
>>
>> On 23.12.21 14:11, Richard Purdie wrote:
>>> On Thu, 2021-12-23 at 12:31 +0100, Konrad Weihmann wrote:
>>>>
>>>> On 23.12.21 11:49, Peter Kjellerstedt wrote:
>>>>>> -----Original Message-----
>>>>>> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Richard Purdie
>>>>>> Sent: den 23 december 2021 00:21
>>>>>> To: openembedded-core@lists.openembedded.org
>>>>>> Subject: [OE-core] [PATCH] base/patch: Disable network for unpack/patch/configure/compile/install
>>>>>>
>>>>>> Use the newly added nonetwork task flag to disable network access where
>>>>>> possible in unpack/patch/configure/compile/install tasks.
>>>>>>
>>>>>> We can't disable networking in sstate tasks due to sstate downloads and
>>>>>> also so we can report hash equivalence to the server.
>>>>>
>>>>> Since no tasks except fetch (and apparently the sstate tasks) are expected
>>>>> to use the network, wouldn't it make more sense to reverse this flag? I.e.,
>>>>> add do_fetch[network] = "1" instead. That way you don't get away with
>>>>> adding some random task and using the network from it unless you explicitly
>>>>> state that you will.
>>>>
>>>> This is actually a brilliant idea, which would also make it easier to
>>>> control this behavior from a user's perspective
>>>
>>> Part of me wonders if we really do want to make this "easy" for the user :/
>>
>> "easier" may have sounded wrong - what I mean is that it would be then
>> explicit, with no network access being the default.
>>
>> So for instance a simple grep on a new layer could confirm whether a
>> layer needs network access or not - while with the opt-out method of
>> your patch things may be a bit more difficult to check.
>>
>> side note: this could also be put into the check-layer script (as I
>> think the official badge shall just go to layers that do not need
>> network access out of the scope defined by core)
>>
>> And yes I got a ton of additional tasks in the layers I work with and
>> none of these would be affected by the opt-in model.
>>
>> Either way, I really love to see this feature finally happen
>>
> Out of curiosity (will see fallout at least on libreoffice): Why is
> this a feature to love?

Simply said because it makes validation of changes way easier.
In before I had to build a change in a normal environment (w network 
access) to verify that it actually builds, then populate some mirror and 
rebuild the same change in an environment without network access.
Now I only will need one run to be sure that it the same recipe will 
even build in 10yrs from now (assuming that a dl-mirror exists).

> 
> Andreas
>