Re: Standardizing NO_NETWORK and USE_SYSTEM_DEPS environment variables

On 2025-01-23 23:38, Michał Górny wrote:
> On Thu, 2025-01-23 at 23:19 +0800, Celeste Liu wrote:
>> On 2025-01-23 21:14, Michał Górny wrote:
>>> 1) NO_NETWORK -- if it's set to a non-empty value, it requests that
>>> programs don't access the (TCP/IP) network.
>>
>> It may be better to be named NO_INTERNET. Network is a confusing word in Linux 
>> world. They can refer to something from only Internet to any protocols in 
>> network subsystem, even include AF_NETLINK... I have been asked why my udev is 
>> broken when my program is in a netns many times. Systemd also have to inform 
>> this point in their document of PrivateNetwork. So use more limited word 
>> Internet to avoid this.
> 
> To be honest, I've been trying to follow the term I've subjectively
> judged to be the most common.  Some projects also use "socket".
> 
> On the other hand, as network namespacing shows, this isn't really
> limited to Internet — we also want to cut stuff from accessing services
> on local network as well.

Yeah. I normal think isolation with Internet and isolation with other parts of 
the same OS are two parts. So I will get confused.

> 
>>>
>>> 2) USE_SYSTEM_DEPS -- if it's set to a non-empty value, it requests that
>>> the build system does not use any vendored dependency for which it
>>> supports using a system version instead, and that it links to shared
>>> libraries whenever possible.
>>> […]
>>
>> Some build system (e.g. Meson) have infrastructure of switch between system 
>> library and vendor library, it's good, we only need to expose the switch via 
>> environment variable.
>>
>> But in many build system, especially in "modern" build system like Go, Cargo 
>> (Rust) and NPM (Node.js), they are not good on this infrastructure:
>>
>> Cargo users normally use feature gate to control whether use system library, but 
>> the gate name and the gate direction are not standardized, someone use 
>> 'vendored-xxx' and some others use 'system-xxx', and in Cargo we can only 
>> control the package behavior we faced directly, not indirect dependencies. if we 
>> want to control the bahavior of dependencies, the only way is hoping ALL the 
>> package author make a feature gate to pass this switch to its dependency.
> 
> Well, I have some Cargo experience, so I'm going to focus on this.
> In my experience, feature-gating is not the only way this is done.  Some
> packages (e.g. zstd-sys) use custom environment variables instead. 
> Others just default to using a system library, with fallback to vendored
> version.
> 
>> In NPM, the situation is even worse. NPM ecosystem prefer to bundle everything. 
>> They have a --build-from-source in node-gyp, but not all package use it and it 
>> only affect the library that will be load by nodejs. In fact, many nodejs 
>> packages, especially which have some web contents, may download a copy of 
>> chromium. The switch for it is not standardized and even not existed in some 
>> projects.
>>
>> For Golang, it doesn't have any infrastructure for switch. Their library is like 
>> an union: either use system library or use vendored version.
>>
>> So the first step may be to build a basic standardized way to use system 
>> resources (include link library and use some executable files) in these language 
>> and build system's ecosystem.
> 
> I am thinking of this proposal as a prelude to that.  What I really
> would like to achieve here is to set some standard variable names, so we
> could work on individual ecosystems and build systems with standards to
> back that work.  In other words, I'd like to avoid having every package
> come up with their own custom ways of doing this — and I'm worried that
> if there's no "standard" behind my effort, different projects will be
> more likely to choose their own variable names (say, NO_INTERNET vs.
> NO_NETWORK vs. DISABLE_INTERNET…), or go for project-local variable
> (FROBNICATE_NO_NETWORK).

I mean that we needn't to inform every projects to make 
NO_NETWORK/USE_SYSTEM_DEPS were used, we just co-work with the build system 
develop team, help them unify the way to use system resources and access network 
in their build system ecosystem, and finally add NO_NETWORK/USE_SYSTEM_DEPS as
a way to control behaviors. i.e. I think it's better to make the build system
become the situation of Meson first, and then add NO_NETWORK/USE_SYSTEM_DEPS
to them. The project developers just treat it as a good new feature of build
system, needn't think the reason and internal implementation too much. The
build system developers do what they are good at (improve the build tool). 
The distro maintainers needn't to communite every projects maintainers. 
The project developers needn't to implement the dependencies handling by
themselves. Everyone will be happy.