On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote: > 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 ...
Do you mean capatilization? It's following suit with other items here.
> > - 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.
>
> > +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.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
