1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [DRAFT v2] GLEP 84: Standard format for package.mask files

    From Arthur Zamarin@21:1/5 to All on Fri Oct 13 16:20:01 2023
    Copy: [email protected]

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M2GxKT7JjyNcyX5CGOZpJqrZ
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    This is the second version of the GLEP after previous recommendations
    and suggestions [1] - thank you for all who participated. Similar to previously, the draft can also be found on glep-0084 branch [2].

    [1] https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/

    [2] https://gitweb.gentoo.org/data/glep.git/tree/glep-0084.rst?h=glep-0084


    ---
    GLEP: 84
    Title: Standard format for package.mask files
    Author: Arthur Zamarin <[email protected]>
    Type: Standards Track
    Status: Draft
    Version: 1.0
    Created: 2023-10-13
    Content-Type: text/x-rst
    ---

    Abstract
    ========

    This GLEP specifies the format of ``package.mask`` files under profiles directory.

    Motivation
    ==========

    At the moment of writing this GLEP, ``package.mask`` files didn't have a full format specification. While PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_ specifies the raw format which the package manager must support for correct behavior, it does not specify how comments must be formatted, how entries must be grouped, how last-rite masks should be written, etc.

    Various tools have been developed to handle that mask message. A non exhaustive list includes ``lr-add-pmask`` [#lr-add-pmask]_, ``pkgdev mask`` [#pkgdev-mask]_,
    and ``soko`` [#soko-mask]_. Those tools have different purposes, filing a new mask message with all relevant information, and showin
  • From Arthur Zamarin@21:1/5 to Ulrich Mueller on Fri Oct 13 18:40:01 2023
    Copy: [email protected]
    Copy: [email protected] (Ulrich Mueller)

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hz3Z21DmyLLi4HxiJIKB1UUf
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 13/10/2023 19.06, Ulrich Mueller wrote:
    On Fri, 13 Oct 2023, Arthur Zamarin wrote:

    Comments Block
    --------------

    The comments block consists of 2 mandatory parts (`author line`_ and
    `explanation`_) and one optional part (`last-rite epilogue`_). A blank line to
    separate the parts is optional. Trailing whitespace should be dropped.

    The lines in the comment block are prefixed with a "#" symbol. The comments >> should be separated with single space from the "#", unless this is trailing >> whitespace, in which case it should be removed (meaning blank lines in comments
    block are just "#\n").

    Maybe flip these two paragraphs? Otherwise it is not entirely clear
    whether the "blank line" mentioned in the first paragraph refers to a
    true blank line, or to a line consisting of a single number sign.

    I agree with you.

    The paragraph should be of format ``Removal on ${DATE}. ${BUGS-LIST}``, where
    the date is RFC-3339 full-date format, meaning ``YYYY-MM-DD``, and the bugs >> list is of the `bugs list`_ format. The listed bugs should include the
    last-rite bug opened, and potentially more relevant bugs which weren't listed
    in the explanation paragraphs.

    Does this mean that only the first of the following entries would be
    valid?

    # Removal on 2023-11-13. Bugs #678901, #890123
    # Removal on 2023-11-13, bugs #678901, #890123.
    # Removal on 2023-11-13. Bugs #678901 #890123

    IMHO that would be too restrictive. Punctuation shouldn't be significant there. (This doesn't preclude _recommending_ one of the variants.)

    Your current interpretation was correct. My main goal is to define a
    "precise" format, so it easy to parse for render of mask (i.e. soko). I
    also think we have nothing to gain from allowing "," instead of "."
    after removal date, but not that I care. Same for bugs-list, I'm fine
    with making the "," optional, but I want us to define a "precise regex"
    so we have consistent format for important bits of mask message. Does
    this seem good enough for you?

    BUGS-LIST ::= [Bb]ugs? #\d+(,? +#\d+)*
    LAST-RITE ::= Removal on {DATE}[.,]? +{BUGS-LIST}.?

    Ulrich

    --
    Arthur Zamarin
    [email protected]
    Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)


    --------------hz3Z21DmyLLi4HxiJIKB1UUf--

    -----BEGIN PGP SIGNATURE-----

    iQEzBAEBCgAdFiEE/axFlFuH2ptjtO5EAqCvUD0SBQQFAmUpcKgACgkQAqCvUD0S BQT60Af+IjocBov2+Z3UtSzxujEOLaNuCDfv3EhUWILO9d6apY7dEehgmx1i/UlR B7MCH/AYRxO9Rm57ojmVHMOvKlCxR40cHZUOGiws8u5vWFQPLMC4e8wHa0an78ph Tn9AxnHk1ChTS3wvot1+wfTTfnlikOmoUPNF9I8DgG9CLiNEL3CoxLi0yrEu0A0r nv0pY9754xk9gQamtmBHasUXXKJg4FdqvYebnUAms4RPRj4u/d8QNx6oaeIkvDzP IvxWw9SGnE+TE2k4USiXHppafp2ij0cSf7mccoJKTzDvi/splT/C8qM8AVCoxJPd mymi5tOWGikhklKKS381ziQQ+DJz4A==
    =hT14
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)