From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0A383158089 for ; Fri, 22 Sep 2023 12:12:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 95D202BC055; Fri, 22 Sep 2023 12:12:41 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5E2522BC013 for ; Fri, 22 Sep 2023 12:12:41 +0000 (UTC) Message-ID: Date: Fri, 22 Sep 2023 15:12:33 +0300 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Arthur Zamarin Subject: Re: [gentoo-dev] Standard parsable format for profiles/package.mask file To: gentoo-dev@lists.gentoo.org References: Content-Language: en-US In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------DAyfrV2kd3OUKH0wVdQOEUlg" X-Archives-Salt: 32b6fb4c-3da9-4482-867a-90f0611f6ad5 X-Archives-Hash: 822bf870ae064580db55a544ca227095 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DAyfrV2kd3OUKH0wVdQOEUlg Content-Type: multipart/mixed; boundary="------------5YHmV7ngiv4PsKyNciP69FRX"; protected-headers="v1" From: Arthur Zamarin Reply-To: gentoo-dev@lists.gentoo.org To: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] Standard parsable format for profiles/package.mask file References: In-Reply-To: --------------5YHmV7ngiv4PsKyNciP69FRX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22/09/2023 00.22, Ulrich Mueller wrote: >>>>>> On Thu, 21 Sep 2023, Arthur Zamarin wrote: >=20 >> =3D=3D=3D=3D=3D "Formal" format =3D=3D=3D=3D=3D >=20 >> Each entry is composed of 2 parts: "#"-prefixed explanation block and >> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new= >> explanation block starts (meaning first "#"-prefixed line after packag= es >> list). You may add newlines between packages in packages list. >=20 > "Must" rather than "may" here? You certainly cannot list several > packages in the same line. Agreed, poor choice of words. >> The first line of the "#"-prefixed explanation block must be of the >> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is o= f >> format YYYY-MM-DD, in UTC timezone. >=20 >> If this is a last-rite message, the last line must list the last-rite >> last date (removal date) and the last-rite bug number. You can also li= st >> other bugs relevant to the last-rite. So I think a format of: "Removal= >> on ${REMOVAL_DATE}. Bug #NNNNNN, #NNNNNN." Where the bug list is comm= a >> and space separated, we have at least one space (" +" regex) between t= he >> removal date and bug list, and the date is of YYYY-MM-DD format. >> I prefer this line is separate (and not continuous of prefix message t= ext). >=20 >> The explanation block itself can reference bugs, by matching the regex= >> "[Bb]ugs? #\d+(, +#\d+)*" (For example: "bug #713106, #753134"). I thi= nk >> this is quite a simple one, but powerful enough for most. >=20 >> Lines with single newline between them (so no blank line between them)= >> are considered as single paragraph continuum. If you want to start new= >> paragraph, leave a blank line (still prefixed with #) - think similar = to >> markdown. A line matching the last-rite line is always it's own paragr= aph. >=20 > Is this rule about paragraphs needed? It is at odds with the rule that > the removal date and bug must be on their own line (i.e. that line is > _not_ part of a "paragraph continuum"). Hmm, yeah, rereading my text shows I've over-complicated it. What I wanted is that last paragraph (yes, if there are many bugs it might wrap into new line) can be not separated with blank line from "main explanation block". > What about the introductory comment block in the file? Should there be = a > defined syntax for a separator between it and the rest of the file? For= > example, everything above the first line matching "^#[ \t]*---" could b= e > ignored by automatic tools, and they would insert new entries below tha= t > separator. Good point, and I should address it as you recommended. I will mention the ignore-until-this-line, and that new entries should be added as first entry after that ignore-until-this-line. >> Should it be a GLEP, I don't think so? But I'm unsure about it. We do >> need to document it (for example header of that exact file). >=20 > It shouldn't be too difficult to wrap this up as a GLEP. OTOH, we don't= > have a GLEP for eclassdoc either. Yeah, after all the input, yes, I will work on a formal GLEP. It will take time, but I hope to prepare a first draft in the coming 2 weeks. > Ulrich --=20 Arthur Zamarin arthurzam@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) --------------5YHmV7ngiv4PsKyNciP69FRX-- --------------DAyfrV2kd3OUKH0wVdQOEUlg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE/axFlFuH2ptjtO5EAqCvUD0SBQQFAmUNhLEACgkQAqCvUD0S BQQBQgf6AmlC7bEWgExuZGfcst21aKglwn5gkbiJYfJzGtb2FsBFPdIjnWx6UvY+ lDWh4+rnzWkUEJggnpclcIC1WpPjvL9BBO/IhJpYBn+923/TJ4eYQEF5waCmnECL LPRldAs3E7pZs4fie0QCOJsfX5VMHQLEq1UWaNAJcTdPXJpKuHov/Dnt6N76IIdS Ki4ETTaVFOK8jffpHjdM+kmHHnB1D1qTizkx2qPTYg7Ge66HFPVav3Z/V6FCX5uX vJIhYbDo0mh3omRugA008VbSGQeybpKJwfBw9DgJmrqFKh1dZx8wMxNM0UV3/Mp5 YPkQHhUfmoS+wXzTYEsXOziR/7duog== =v5Wp -----END PGP SIGNATURE----- --------------DAyfrV2kd3OUKH0wVdQOEUlg--