Quoting Helmut Grohne (2025-11-16 18:08:31) > > > For a dependency to be ignored, it is > > > +enough for either the architecture restriction list or the build profile > > > +restriction formula to evaluate to false. If the dependency with a > > > +restriction is part of a set of alternatives, the alternative for which > > > +either restriction does not apply is ignored and the other alternatives > > > +remain for evaluation. > > > > "remain for evaluation" seems vague. > > > > I think you are trying to capture how a system consuming these files is > > allowed to consider only the first alternative? > > > > Could you just say that each restriction applies separately to each > > alternative? > > You are not the only one being confused. Rewritten. Thanks.
The new version now reads: 97 +host architecture and a set of enabled build profiles. Their results 98 +indicate whether the dependency alternative should be considered or 99 +ignored. For a dependency alternative to be considered, the architecture 100 +restriction list (if any) and the build profile restriction formula (if 101 +any) must evaluate to true. A dependency is considered satisfied if none 102 +of its alternatives apply. I have a problem with the last sentence. I think saying that a dependency is considered "satisfied" is wrong here. The dependency is not satisfied, it is "considered" instead of being "ignored" by a solver and then that solver decides about whether or not a dependency is satisfied in the context of a package universe. Or am I misunderstanding what you want to say with the last sentence? This is opposed to the next paragraph: 105 +the restriction appears. A restriction in one of the build relationship 106 +fields (``Build-Depends``...) that does not match means that the 107 +build-dependency is not required to be satisfied for the package to be 108 +built. Here, the word "satisfied" makes sense. Then further below there is this example: 193 +In the next example, the source package would build-depend on ``foo`` if 194 +``nopython`` is disabled and at least one of ``nocheck`` and 195 +``nopython`` is disabled. 196 + 197 +:: 198 + 199 + Build-Depends: foo <!nopython !nocheck> <!nopython !noinsttest> I think you want to replace the last nopython with noinsttest to make the text fit the restriction formula example. > As much as we may continue word smithing this text, I suggest that the > perfect is the enemy of the good. By now, not having this text in policy > seems worse to me than having a buggy description of build profiles. I agree and I do not consider my two remarks above significant enough to block this bug. The current version of this text has my approval with or without my remarks getting fixed. Thank you all! cheers, josch
signature.asc
Description: signature
