1 |
My goal here is to improve the speed at which developers work and |
2 |
making it easier to do things, hence the 'automation' series of mails |
3 |
(of which this is the first of hopefully many). |
4 |
|
5 |
Todays subject is package.mask. |
6 |
|
7 |
Package.mask is a file read by both the package mangler and humans to |
8 |
determine if a given CP(V) is masked or not, and also to try and |
9 |
determine who did the masking, when, and why. |
10 |
|
11 |
None of these fields are required, but are usually present by convention. |
12 |
|
13 |
The intent here is to formalize the format of package.mask by |
14 |
introducing what i'll term 'fields'. Fields may be required, or |
15 |
optional. Fields may contain data, typically in the form of ASCII |
16 |
text. The intent of adding fields is to ensure that all masks contain |
17 |
mandatory information. |
18 |
|
19 |
Right now the present convention would have the following fields. |
20 |
|
21 |
Author: Who commited the mask. |
22 |
Date: When was it masked. |
23 |
Reason: 1 or more lines describing a rationale for the masking. |
24 |
Packages: one or more lines of text, 1 atom per line, describing |
25 |
packages affected by this mask entry. |
26 |
|
27 |
I wish to add a few more fields: |
28 |
|
29 |
Effective-Date: Date the mask goes into effect. This means you can |
30 |
mask stuff in the future. |
31 |
Expiration-Date: Date the mask ends. This means you can have masks |
32 |
that expire after a given time. |
33 |
|
34 |
If Expiration-Date was mandatory, we could essentially have a system |
35 |
that cleans out mask files by removing expired masks. |
36 |
|
37 |
I currently am seeking feedback about the idea of adding more fields |
38 |
to package.mask and the examples provided in this e-mail in no way |
39 |
represent any given implementation (for which there is currently |
40 |
none). Certainly adding more fields places a burden on the package |
41 |
manager to exclude entries that are not within the Effectived -> |
42 |
Expiration date range. And of course, backwards compatability is |
43 |
always a bitch. |
44 |
|
45 |
Another thing I wish to address is the addition of entries in |
46 |
package.mask at the top of the file. I think this restriction just |
47 |
makes automation more difficult. I can't just append new entries to |
48 |
the end of the file, I have to read in the file and figure out by some |
49 |
hardcoded comment strings where the actaul masks begin, and then |
50 |
insert text right below the examples. This is horrible. Can we nuke |
51 |
that convention, why are new entries at the top? |
52 |
|
53 |
-Alec |
54 |
-- |
55 |
gentoo-project@g.o mailing list |