-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
On 2020/09/16 11:39, Michał Górny wrote:
> On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
>>
>>> +- at most one ``<stabilization-candidates/>`` element containing
version
>>> + constraints used to determine stabilization candidates, as detailed
>>> + in `Stabilization candidates`_.
>>> +
>> At most one ...
>
> Do you mean capatilization? It's following suit with other items here.
Sorry, was unclear, this correlates with the second comment below.
>>> - zero or more ``<stabilize-allarches/>`` elements, possibly restricted
>>> to specific package versions (at most one for each version) whose
presence
>>> indicates that the appropriate ebuilds are suitable for
simultaneously
>>> @@ -199,6 +203,25 @@ The ``<slots/>`` element can contain the
following elements:
>>> - at most one ``<subslots/>`` element describing the role of
subslots (all
>>> of them) as text.
>>>
>>> +Stabilization candidates
>>> +~~~~~~~~~~~~~~~~~~~~~~~~
>>> +Each ``<stabilization-candidates/>`` element describes version
>>
>> vs each (implies any number). I'd simply say, "If present, the
``<stab..."
>
> Again, this follows suit with other descriptions.
If this is the standard, this is the standard, was just trying to point
out that this could be considered a conflict.
>>> +constraints used to determine package versions eligible
>>> +for stabilization. Should this element be missing, the tooling assumes
>>> +a default of any version with any keywords present (i.e. the equivalent
>>> +of ``>=0``).
>>> +
>>> +The ``<stabilization-candidates/>`` element can contain the following
>>> +elements:
>>> +
>>> +- one or more ``<version/>`` elements, each containing a version
>>> + constraint in the format matching EAPI 0 dependency specification
>>> + with the package category and name parts omitted, e.g. ``<1.7``.
>>> + The tooling considers any ebuild version that satisfies the
constraint
>>> + and has any keywords. If multiple constraints are provided,
every one
>>> + of them is matched separately, and multiple stabilization candidates
>>> + can be reported.
>>
>> I think it's clear from context that there should be one or more, but
>> the language ("can contain" in the leading paragraph) implies all sub
>> elements are optional. Perhaps:
>>
>> The ... element:
>>
>> - must contain one or more ...
>>
>> Which also allows for future "may contain" sub elements.
>>
>
> To be honest, I'm not sure if we should permit or prohibit empty element
> in the spec.
pick one. But I'd use the word may (clearly optional) or must (clearly
compulsory) rather than can.
Kind Regards,
Jaco
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl9h9YMACgkQCC3Esa/3
7p5XtQf9H6kcStCzBz75rOVhoswzhIafZWXJnurAYHvEvM3vrWrMzh46Bc3aZZLo
fo2+lg7Z9lw0iBxJjub/nexBR9D8XwCa3aW/G75Hgd5XcC54LfKRFGqGKHS9Zu9z
GT96Ijqo4aS2PlepD0Qk8jVTnngzB5opasH3nNgR2u6WSEQHtkCE8lg2A1Z0hr3i
PmO/kzvHnZxsais9wp7kkZn+ftGbI1Wuq6Gus3Yy3qWp2k6KTwD49VdN3y7Skk3s
T3ULl/+ui/FqwGGDjlQw0MW8o2mJ76VrQoMTiMG7IErFz9BzJ3djf/bgXg8YjHc5
kjo/h1tLcj7WvLphz9gdhGt4Sk85Sw==
=WdPf
-----END PGP SIGNATURE-----
