Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Automation: Making package.mask better
Date: Sun, 22 Jul 2007 06:40:02
Message-Id: b41005390707212339s10f3dc54rac0364457853353@mail.gmail.com
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

Replies