1 |
On Wed, 2021-05-19 at 11:22 -0400, Wolfgang E. Sanyer wrote: |
2 |
> On Wed, May 19, 2021 at 11:02 AM Michał Górny <mgorny@g.o> wrote: |
3 |
> > |
4 |
> > On Wed, 2021-05-19 at 10:37 -0400, Wolfgang E. Sanyer wrote: |
5 |
> > > See some comments in-line below. |
6 |
> > > |
7 |
> > > |
8 |
> > > On Wed, May 19, 2021 at 8:33 AM Michał Górny <mgorny@g.o> wrote: |
9 |
> > > > |
10 |
> > > > Hi, |
11 |
> > > > |
12 |
> > > > Please review the pre-GLEP inlined below. Its purpose is to formally |
13 |
> > > > define the format of layout.conf. It's pretty much inevitable these |
14 |
> > > > days, so we should specify it. However, it doesn't really fit into PMS, |
15 |
> > > > and other formats (Manifests, metadata.xml) are already defined |
16 |
> > > > in GLEPs, so this just follows suit. |
17 |
> > > > |
18 |
> > > > Pre-GLEP follows. |
19 |
> > > > |
20 |
> > > > --- |
21 |
> > > > GLEP: 9999 |
22 |
> > > > Title: Repository configuration file (layout.conf) |
23 |
> > > > Author: Michał Górny <mgorny@g.o> |
24 |
> > > > Type: Standards Track |
25 |
> > > > Status: Draft |
26 |
> > > > Version: 1.0 |
27 |
> > > > Created: 2021-05-19 |
28 |
> > > > Last-Modified: 2021-05-19 |
29 |
> > > > Post-History: 2021-05-19 |
30 |
> > > > Content-Type: text/x-rst |
31 |
> > > > --- |
32 |
> > > > |
33 |
> > > > Abstract |
34 |
> > > > ======== |
35 |
> > > > |
36 |
> > > > The ``metadata/layout.conf`` file format is specified as used by Portage |
37 |
> > > > and PkgCore. A standard set of configuration keys is described |
38 |
> > > > including the keys currently used in the Gentoo repository. |
39 |
> > > > |
40 |
> > > > |
41 |
> > > > Motivation |
42 |
> > > > ========== |
43 |
> > > > |
44 |
> > > > The ``metadata/layout.conf`` file was first added to the Gentoo |
45 |
> > > > repository in Oct 2011, to facilitate setting of hashes used |
46 |
> > > > in Manifest2 files. In Mar 2012, it was used to indicate the transition |
47 |
> > > > to the new ``md5-dict`` cache format. In Jul 2013, it started being |
48 |
> > > > used to indicate the repository's masters and effectively became |
49 |
> > > > obligatory for all repositories. |
50 |
> > > > |
51 |
> > > > Today, ``layout.conf`` is used for various repository configuration |
52 |
> > > > knobs that can be expressed as simple values and therefore |
53 |
> > > > do not justify adding new files to the repository. This primarily |
54 |
> > > > involves the configuration of development tools but also includes a few |
55 |
> > > > keys relevant to the behavior of the package manager. |
56 |
> > > > |
57 |
> > > > However, ``layout.conf`` is currently not covered by any formal |
58 |
> > > > specification. The PMS neglects its existence entirely, and the keys |
59 |
> > > > used are roughly defined by their first use of Portage or PkgCore. |
60 |
> > > > This GLEP aims to overcome this by providing a formal specification |
61 |
> > > > for the file, as well as an up-to-date list of permitted configuration |
62 |
> > > > keys. |
63 |
> > > > |
64 |
> > > > |
65 |
> > > > Specification |
66 |
> > > > ============= |
67 |
> > > > |
68 |
> > > > layout.conf file format |
69 |
> > > > ----------------------- |
70 |
> > > > |
71 |
> > > > Every ebuild repository must contain a ``metadata/layout.conf`` file. |
72 |
> > > > The file uses a line-oriented text format. Lines starting with ``#`` |
73 |
> > > > represent comments and are ignored, as are lines consisting entirely |
74 |
> > > > of whitespace. The remaining lines must contain a key followed |
75 |
> > > > by equals sign (``=``), followed by a (possibly empty) value. Each of |
76 |
> > > > these elements can be surrounded by additional whitespace that |
77 |
> > > > is stripped. |
78 |
> > > |
79 |
> > > Is a space around the "=" optional? I see it used below, but here it sounds |
80 |
> > > like there should be no space. |
81 |
> > |
82 |
> > The last sentence says you can add extra space and it will be stripped. |
83 |
> > If you can think of a better way of wording that (I really wanted to |
84 |
> > avoid 'optional whitespace, followed by key, followed by optional |
85 |
> > whitespace... ' ;-). |
86 |
> |
87 |
> 🤦♂️ ofc I would miss that. |
88 |
> |
89 |
> I always thought that python did a pretty good job |
90 |
> [explaining their format mini-language][1]. That's obviously overkill for what |
91 |
> you're describing here, but maybe something like this would be helpful? |
92 |
> |
93 |
> # comments are allowed |
94 |
> <key> = [<value1> [<value2>...]] |
95 |
> |
96 |
> Any lines starting with a ``#`` represents a comment and are ignored, as are |
97 |
> lines consisting entirely of whitespace. |
98 |
> |
99 |
> A valid line consists of key and an equal sign. (A valid key is a |
100 |
> string containing |
101 |
> any character except for a space)[^1]. The list of space-separated |
102 |
> values is optional. |
103 |
> |
104 |
> Note: any additional spaces are ultimately stripped |
105 |
> |
106 |
> [1]: https://docs.python.org/3/library/string.html#format-specification-mini-language |
107 |
> [^1]: Should we include this or nah? |
108 |
|
109 |
Thanks, this looks like a nice idea. I'm going to send a v2 shortly |
110 |
and we'll see how it worked out. |
111 |
|
112 |
> |
113 |
> > > |
114 |
> > > > Configuration keys |
115 |
> > > > ------------------ |
116 |
> > > > |
117 |
> > > > The ``layout.conf`` file must contain the ``masters`` key. Other keys |
118 |
> > > > listed in this specification are entirely optional. The package |
119 |
> > > > managers may choose to implement a subset of listed keys. Unknown keys |
120 |
> > > > must be ignored. |
121 |
> > > > |
122 |
> > > > The following keys are currently defined: |
123 |
> > > |
124 |
> > > Is the intent for the GLEP to define and specify every possible key-value |
125 |
> > > combination? If not, then perhaps this section should be truncated a bit? i.e. |
126 |
> > > "here are some examples of currently defined keys" and then list a handful. |
127 |
> > > |
128 |
> > > Additionally, maybe the spec should include some sort of requirement for |
129 |
> > > documentation of variables, similar to what you've done below. |
130 |
> > > |
131 |
> > > Edit: ok, nevermind I see your recommendation at the bottom. But still, |
132 |
> > > I would probably either (1) insist that new keys be added to this GLEP, or |
133 |
> > > (2) insist that new keys are documented properly. |
134 |
> > |
135 |
> > Let's put it like this: the goal is to document all the useful keys. |
136 |
> > I can live with some ancient-not-really-useful keys not being documented |
137 |
> > (e.g. Portage has some stale/redundant Manifest-related keys, I think). |
138 |
> |
139 |
> Perhaps then some sort of use of the word "reserved" should be in here? |
140 |
> i.e. "The following keys are reserved for use by portage and pkgcheck. |
141 |
> any other keys may be defined and used at will" |
142 |
> |
143 |
> > > |
144 |
> > > > masters = <space-separated values> |
145 |
> > > > Specifies the master repositories of this repository. For stand-alone |
146 |
> > > > repositories, this must be set to an empty value. Otherwise, it can |
147 |
> > > > list one or more repositories, separated by spaces. This key must |
148 |
> > > > be specified. |
149 |
> > > |
150 |
> > > I realize this is the only compulsory key, but perhaps it should still go in |
151 |
> > > a separate section in order to ensure that it stands out? i.e. "The following |
152 |
> > > keys are mandory..." and then later "the following optional keys are |
153 |
> > > currently defined" |
154 |
> > |
155 |
> > I'm not sure, to be honest. I didn't really want to add a section for |
156 |
> > one key ;-). |
157 |
> |
158 |
> np, just a thought. |
159 |
> |
160 |
> > > |
161 |
> > > > manifest-hashes = <space-separated values> |
162 |
> > > > Specifies the list of hashes that should be used for new distfiles |
163 |
> > > > in the Manifest files. The development tools may create a subset |
164 |
> > > > of the specified hashes if it is not updating the checksums for |
165 |
> > > > the specified distfile, or does not support the hash in question. |
166 |
> > > > The hash names are specified in GLEP 74. [#GLEP74]_ The default |
167 |
> > > > set of hashes is implementation-defined. |
168 |
> > > > |
169 |
> > > > manifest-required-hashes = <space-separated values> |
170 |
> > > > Specifies the list of hashes that must be used in Manifest files. |
171 |
> > > > The development tools must support all the hashes listed there, |
172 |
> > > > and update distfile checksums to use these hashes (refetching |
173 |
> > > > if necessary). This must be a subset of manifest-hashes. If not |
174 |
> > > > specified, all hashes from manifest-hashes (or the default set) |
175 |
> > > > are considered required. |
176 |
> > > > |
177 |
> > > > use-manifests = ``strict``, ``true`` or ``false`` |
178 |
> > > > Indicates the policy for creating and using Manifest files. If set |
179 |
> > > > to ``strict``, Manifest files are created and files are required to |
180 |
> > > > match digests found in Manifests. If set to ``true``, Manifests |
181 |
> > > > are created but digest mismatches are ignored. If set to ``false``, |
182 |
> > > > Manifests are not used at all. The default is ``strict``. |
183 |
> > > > |
184 |
> > > > update-changelog = ``true`` or ``false`` |
185 |
> > > > Indicates whether the development tools should write ChangeLog files. |
186 |
> > > > The default is ``false``. |
187 |
> > > > |
188 |
> > > > cache-formats = <space-separated values> |
189 |
> > > > Specifies one or more cache formats used by the repository. |
190 |
> > > > The currently defined values are ``pms`` for the original format |
191 |
> > > > specified in the PMS and ``md5-dict`` for the md5-dict format |
192 |
> > > > introduced in Portage 2.2.0_alpha68. The default is |
193 |
> > > > implementation-defined. |
194 |
> > > > |
195 |
> > > > eapis-deprecated = <space-separated values> |
196 |
> > > > Specifies one or more EAPIs that are to be considered deprecated |
197 |
> > > > by the development tools for use in ebuilds, i.e. their use should |
198 |
> > > > trigger a warning. If not specified, no EAPIs are deprecated. |
199 |
> > > > |
200 |
> > > > eapis-banned = <space-separated values> |
201 |
> > > > Specifies one or more EAPIs that are to be considered banned |
202 |
> > > > by the development tools for use in ebuilds, i.e. their use should |
203 |
> > > > be blocked. If not specified, no EAPIs are banned. |
204 |
> > > > |
205 |
> > > > repo-name = <string> |
206 |
> > > > Specifies the repository name. If specified, it must be equal |
207 |
> > > > to the contents of ``profiles/repo_name``. If not specified, |
208 |
> > > > it defaults to the same value. Discouraged. |
209 |
> > > > |
210 |
> > > > aliases = <space-separated values> |
211 |
> > > > Specified one or more additional names that can be used to reference |
212 |
> > > > the repository (e.g. in repository dependencies). If not specified, |
213 |
> > > > no aliases are defined. |
214 |
> > > > |
215 |
> > > > thin-manifests = ``true`` or ``false`` |
216 |
> > > > If enabled, Manifest files in the package directory must contain only |
217 |
> > > > ``DIST`` entries. If disabled, Manifest files in the package |
218 |
> > > > directory must list digests for all files found in the package |
219 |
> > > > directory and the files directory. The default is ``false``. |
220 |
> > > > |
221 |
> > > > sign-commits = ``true`` or ``false`` |
222 |
> > > > Indicates whether git commits are to be signed (using ``git commit |
223 |
> > > > --gpg-sign``. The default is ``false``. |
224 |
> > > > |
225 |
> > > > sign-manifests = ``true`` or ``false`` |
226 |
> > > > Indicates whether individual package Manifests should be PGP-signed. |
227 |
> > > > Note that this refers to the historical behavior of signing individual |
228 |
> > > > Manifests, not the GLEP 74 behavior of signing the top-level Manifest. |
229 |
> > > > [#GLEP74]_ The default is ``true`` if PGP signing is configured. |
230 |
> > > > |
231 |
> > > > properties-allowed = <space-separated values> |
232 |
> > > > Specifies the list of ``PROPERTIES`` tokens that are permitted |
233 |
> > > > to be used in ebuilds. If present, the development tools should issue |
234 |
> > > > a warning if ``PROPERTIES`` contains any tokens that are not listed |
235 |
> > > > here. If not specified, all tokens are permitted. |
236 |
> > > > |
237 |
> > > > restrict-allowed = <space-separated values> |
238 |
> > > > Same as properties-allowed, except for ``RESTRICT``. |
239 |
> > > > |
240 |
> > > > profile-formats = <space-separated values> |
241 |
> > > > Specifies the format used by profiles and/or extensions to it. |
242 |
> > > > The default is ``pms`` indicating the format specified in the PMS. |
243 |
> > > > Other values are implementation-defined. |
244 |
> > > > |
245 |
> > > > |
246 |
> > > > It is recommended that any future keys are added to this GLEP before |
247 |
> > > > being implemented. |
248 |
> > > > |
249 |
> > > > |
250 |
> > > > Example |
251 |
> > > > ------- |
252 |
> > > > |
253 |
> > > > The following is an example configuration for a git repository with |
254 |
> > > > Gentoo set as a master:: |
255 |
> > > > |
256 |
> > > > masters = gentoo |
257 |
> > > > |
258 |
> > > > # git: do not use ChangeLog, use thin, unsigned Manifests |
259 |
> > > > update-changelog = false |
260 |
> > > > thin-manifests = true |
261 |
> > > > sign-manifests = false |
262 |
> > > > |
263 |
> > > > # force the new md5-dict cache format |
264 |
> > > > cache-formats = md5-dict |
265 |
> > > > |
266 |
> > > > |
267 |
> > > > Rationale |
268 |
> > > > ========= |
269 |
> > > > |
270 |
> > > > This GLEP is written almost 10 years after ``layout.conf`` was |
271 |
> > > > originally introduced. This made it necessary to write it in such a way |
272 |
> > > > that both the modern and historical implementations in Portage |
273 |
> > > > and PkgCore, as well as the use in the Gentoo repository |
274 |
> > > > and a reasonably large subset of the other repositories would remain |
275 |
> > > > compliant. |
276 |
> > > > |
277 |
> > > > The historical default of assuming ``masters = gentoo`` when unspecified |
278 |
> > > > is omitted as it is not portable and verbosely deprecated for many |
279 |
> > > > years in Portage. All repositories are required to explicitly specify |
280 |
> > > > their masters, or an empty value if they are stand-alone. |
281 |
> > > > |
282 |
> > > > The default for Manifest hashes and cache formats are left to be |
283 |
> > > > implementation-defined, as the defaults changed over time and do not |
284 |
> > > > match between package managers. In particular, Portage attempts to |
285 |
> > > > autodetect the cache format currently used in a given repository. |
286 |
> > > > |
287 |
> > > > The repo-name key has been originally added as an alternative to |
288 |
> > > > ``profiles/repo_name``. However, the latter file is still required |
289 |
> > > > for PMS compliance. Furthermore, given that it is much easier to parse, |
290 |
> > > > there seems to be no appealing reason to work towards replacing that |
291 |
> > > > file. This means that for all practical reasons, the repo-name key |
292 |
> > > > is redundant and is listed here for completeness only. |
293 |
> > > > |
294 |
> > > > The profile-formats key has been introduced to permit Portage-specific |
295 |
> > > > extensions to the profile directory without having to introduce custom |
296 |
> > > > EAPIs. The exact extensions are considered outside the scope of this |
297 |
> > > > specification. |
298 |
> > > > |
299 |
> > > > |
300 |
> > > > Backwards Compatibility |
301 |
> > > > ======================= |
302 |
> > > > |
303 |
> > > > The existing implementations found in Portage and PkgCore conform |
304 |
> > > > to this specification, so does the ``metadata/layout.conf`` file |
305 |
> > > > found in the Gentoo repository. |
306 |
> > > > |
307 |
> > > > |
308 |
> > > > Reference Implementation |
309 |
> > > > ======================== |
310 |
> > > > |
311 |
> > > > The support for ``metadata/layout.conf`` is already a part of Portage |
312 |
> > > > and PkgCore. |
313 |
> > > > |
314 |
> > > > |
315 |
> > > > References |
316 |
> > > > ========== |
317 |
> > > > |
318 |
> > > > .. [#GLEP74] GLEP 74: Full-tree verification using Manifest files |
319 |
> > > > (https://www.gentoo.org/glep/glep-0074.html) |
320 |
> > > > |
321 |
> > > > |
322 |
> > > > Copyright |
323 |
> > > > ========= |
324 |
> > > > |
325 |
> > > > This work is licensed under the Creative Commons Attribution-ShareAlike |
326 |
> > > > 4.0 |
327 |
> > > > International License. To view a copy of this license, visit |
328 |
> > > > https://creativecommons.org/licenses/by-sa/4.0/. |
329 |
> > > > |
330 |
> > > > |
331 |
> > > > -- |
332 |
> > > > Best regards, |
333 |
> > > > Michał Górny |
334 |
> > > > |
335 |
> > > > |
336 |
> > > > |
337 |
> > > |
338 |
> > |
339 |
> > -- |
340 |
> > Best regards, |
341 |
> > Michał Górny |
342 |
> > |
343 |
> > |
344 |
> > |
345 |
> |
346 |
|
347 |
-- |
348 |
Best regards, |
349 |
Michał Górny |