| 1 |
On Sunday, 22. July 2007 08:39, Alec Warner wrote: |
| 2 |
> Author: Who commited the mask. |
| 3 |
> Date: When was it masked. |
| 4 |
> Reason: 1 or more lines describing a rationale for the masking. |
| 5 |
> Packages: one or more lines of text, 1 atom per line, describing |
| 6 |
> packages affected by this mask entry. |
| 7 |
> |
| 8 |
> I wish to add a few more fields: |
| 9 |
> |
| 10 |
> Effective-Date: Date the mask goes into effect. This means you can |
| 11 |
> mask stuff in the future. |
| 12 |
> Expiration-Date: Date the mask ends. This means you can have masks |
| 13 |
> that expire after a given time. |
| 14 |
> |
| 15 |
> If Expiration-Date was mandatory, we could essentially have a system |
| 16 |
> that cleans out mask files by removing expired masks. |
| 17 |
|
| 18 |
I like the idea, here's my comments: |
| 19 |
|
| 20 |
1. For backwards compatibility, we could just put all fields into |
| 21 |
comments (as it is done now) except for the masked atoms, like this: |
| 22 |
|
| 23 |
# Author: Alec Warner <antarus@g.o> |
| 24 |
# Date: 05 Feb 2007 |
| 25 |
# Reason: Masked to security problems, use 1.23-r1 until I fix it |
| 26 |
# ... |
| 27 |
>=app-admin/ulogd-1.24 |
| 28 |
|
| 29 |
The dates usage and parsing could than be added later, while using the |
| 30 |
format and automation itself today. |
| 31 |
|
| 32 |
2. The pro's of using it today would be to mark Last-Rites (just what |
| 33 |
makes me think that discussion led you to the idea?). |
| 34 |
I can think of several ways to do this. We could have an |
| 35 |
optional "Removal-Date" field and if it is set, the package is last |
| 36 |
rited |
| 37 |
|
| 38 |
3. We could also introduce some kind of "Keywords" as in Bugzilla to |
| 39 |
mark certain situations, as UNUSABLE, SECURITY, LASTRITED. Do we need |
| 40 |
that? |
| 41 |
|
| 42 |
4. How do we handle updates to the an entry, esp. the Date and Author |
| 43 |
section? |
| 44 |
|
| 45 |
|
| 46 |
> Another thing I wish to address is the addition of entries in |
| 47 |
> package.mask at the top of the file. I think this restriction just |
| 48 |
> makes automation more difficult. I can't just append new entries to |
| 49 |
> the end of the file, I have to read in the file and figure out by |
| 50 |
> some hardcoded comment strings where the actaul masks begin, and then |
| 51 |
> insert text right below the examples. This is horrible. Can we nuke |
| 52 |
> that convention, why are new entries at the top? |
| 53 |
|
| 54 |
Drop the convention then... or we could add a marker line at the top |
| 55 |
"## New entries start here" - Would that make it easier? |
| 56 |
|
| 57 |
Robert |
| 58 |
-- |
| 59 |
gentoo-project@g.o mailing list |
Archives