List Archive: gentoo-project
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
My goal here is to improve the speed at which developers work and
making it easier to do things, hence the 'automation' series of mails
(of which this is the first of hopefully many).
Todays subject is package.mask.
Package.mask is a file read by both the package mangler and humans to
determine if a given CP(V) is masked or not, and also to try and
determine who did the masking, when, and why.
None of these fields are required, but are usually present by convention.
The intent here is to formalize the format of package.mask by
introducing what i'll term 'fields'. Fields may be required, or
optional. Fields may contain data, typically in the form of ASCII
text. The intent of adding fields is to ensure that all masks contain
Right now the present convention would have the following fields.
Author: Who commited the mask.
Date: When was it masked.
Reason: 1 or more lines describing a rationale for the masking.
Packages: one or more lines of text, 1 atom per line, describing
packages affected by this mask entry.
I wish to add a few more fields:
Effective-Date: Date the mask goes into effect. This means you can
mask stuff in the future.
Expiration-Date: Date the mask ends. This means you can have masks
that expire after a given time.
If Expiration-Date was mandatory, we could essentially have a system
that cleans out mask files by removing expired masks.
I currently am seeking feedback about the idea of adding more fields
to package.mask and the examples provided in this e-mail in no way
represent any given implementation (for which there is currently
none). Certainly adding more fields places a burden on the package
manager to exclude entries that are not within the Effectived ->
Expiration date range. And of course, backwards compatability is
always a bitch.
Another thing I wish to address is the addition of entries in
package.mask at the top of the file. I think this restriction just
makes automation more difficult. I can't just append new entries to
the end of the file, I have to read in the file and figure out by some
hardcoded comment strings where the actaul masks begin, and then
insert text right below the examples. This is horrible. Can we nuke
that convention, why are new entries at the top?
email@example.com mailing list