1 |
On 10/17/2017 02:12 PM, Michał Górny wrote: |
2 |
> |
3 |
> Abstract |
4 |
> ======== |
5 |
> |
6 |
> ... |
7 |
> The QA checks can inspect the installation image or live system respectively, |
8 |
|
9 |
Respective to what? |
10 |
|
11 |
|
12 |
> output and store both user- and machine-oriented QA warning logs, manipulate |
13 |
> the files and abort the install, as necessary. |
14 |
> |
15 |
|
16 |
An oxford comma would make that easier to read: "files, and abort the |
17 |
install as necessary." |
18 |
|
19 |
|
20 |
> Motivation |
21 |
> ========== |
22 |
> |
23 |
> ... |
24 |
> |
25 |
> Over time, many different QA checks have been added to Portage. That includes |
26 |
> checks corresponding to generic Gentoo rules (like filesystem hierarchy, |
27 |
> security requirements), checks enforcing Gentoo team policies and correct |
28 |
> eclass uses. |
29 |
|
30 |
Another weird comma issue, maybe try: "policies, and checks enforcing |
31 |
correct eclass usage." |
32 |
|
33 |
|
34 |
|
35 |
> There are two kinds of QA checks defined in this specification: |
36 |
> |
37 |
> 1. Post-install QA checks (``install-qa-check.d``), |
38 |
> |
39 |
> 2. Post-merge (postinst) QA checks (``postinst-qa-check.d``). |
40 |
> |
41 |
|
42 |
It's a bit sadistic to have something called a "post-install check" but |
43 |
then have "postinst check" refer to the other thing. |
44 |
|
45 |
|
46 |
> |
47 |
> In case of severe QA issues, the checks are allowed to alter the contents of |
48 |
> the installation image in order to sanitize them, or call the ``die`` function |
49 |
> to abort the build. |
50 |
|
51 |
I'm not sure that having the image silently modified is a good idea. It |
52 |
seems like everyone would benefit more if the QA check crashed, and let |
53 |
the maintainer fix his ebuild. Is this already possible with the Portage |
54 |
checks, or is it new in the repository-based checks? |
55 |
|
56 |
|
57 |
> |
58 |
> The post-merge QA checks are executed after the ``pkg_postinst`` ebuild phase |
59 |
> finishes. They can use the same commands as are permitted in ``pkg_postinst``, |
60 |
> and access the installed system location ``${ROOT}`` and the temporary |
61 |
> directory ``${T}``. |
62 |
> |
63 |
> The checks are allowed to alter the contents of the filesystem to the same |
64 |
> degree as ``pkg_postinst`` phase is. They must not call ``die``. |
65 |
|
66 |
Ditto re: filesystem modification. |
67 |
|
68 |
|
69 |
|
70 |
> |
71 |
> Aside to the standard PMS function |
72 |
> |
73 |
|
74 |
Aside from |
75 |
|
76 |
|
77 |
|
78 |
> eqatag |
79 |
> ~~~~~~ |
80 |
> Synopsis |
81 |
> ``eqatag [-v] <tag> [<key>=<value>...] [<file>...]`` |
82 |
> |
83 |
> Tag the package with specific QA issues. The *tag* parameter is |
84 |
> a well-defined name identifying specific QA issue. The tag can be additionally |
85 |
> associated with some data in key-value form and/or one or more *files*. |
86 |
> The file paths are relative to installation image (``${D}``), and need to |
87 |
> start with a leading slash. |
88 |
|
89 |
If this is used in a post-merge check, isn't it conceivable that you |
90 |
would want to tag a path outside of $D? For example, if your src_install |
91 |
creates ${D}/bin/foo and then your pkg_postinst phase gives ownership of |
92 |
/bin/foo to the "foo" user, I might want to tag /bin/foo (and not |
93 |
${D}/bin/foo) with a bad-owner tag. |
94 |
|
95 |
|
96 |
> |
97 |
> The two types of QA checks were created to account for different kinds |
98 |
> of common mistakes in ebuilds. |
99 |
> |
100 |
> ... |
101 |
> |
102 |
> Post-postinst QA checks can be used to verify the state of system after |
103 |
|
104 |
I think we're calling these "Post-merge" checks. |
105 |
|
106 |
|
107 |
|
108 |
> |
109 |
> QA check script format |
110 |
> ---------------------- |
111 |
> |
112 |
|
113 |
This is the second appearance of a "QA check script format" section. |
114 |
|
115 |
|
116 |
> |
117 |
> Function specification |
118 |
> ---------------------- |
119 |
|
120 |
|
121 |
Also appears twice. |