Hi Michał,
Thanks for your efforts. This looks interesting at the very least, and
whilst in many cases on posts on this ML I'm on the "don't care" stance,
this one looks like it could solve some problems for me.
net-misc/asterisk + friends will definitely make use of this.
Two nitpicks below that doesn't really carry significant meaning.
On 2020/09/16 07:48, Michał Górny wrote:
> Signed-off-by: Michał Górny <mgo...@gentoo.org>
> ---
> glep-0068.rst | 62 ++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0068.rst b/glep-0068.rst
> index d8fc379..5b7e2b9 100644
> --- a/glep-0068.rst
> +++ b/glep-0068.rst
> @@ -4,10 +4,10 @@ Title: Package and category metadata
> Author: Michał Górny <mgo...@gentoo.org>
> Type: Standards Track
> Status: Final
> -Version: 1.1
> +Version: 1.2
> Created: 2016-03-14
> -Last-Modified: 2020-05-06
> -Post-History: 2016-03-16, 2018-02-20
> +Last-Modified: 2020-09-16
> +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
> Content-Type: text/x-rst
> Requires: 67
> Replaces: 34, 46, 56
> @@ -149,6 +149,10 @@ element can contain, in any order:
> languages (at most one for each language), as detailed
> in `Slot descriptions`_.
>
> +- at most one ``<stabilization-candidates/>`` element containing version
> + constraints used to determine stabilization candidates, as detailed
> + in `Stabilization candidates`_.
> +
At most one ...
> - 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..."
> +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.
Kind Regards,
Jaco
