Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-project
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-project@g.o
From: "Alec Warner" <antarus@g.o>
Subject: Automation: Making package.mask better
Date: Sat, 21 Jul 2007 23:39:51 -0700
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
mandatory information.

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?

-Alec
-- 
gentoo-project@g.o mailing list


Replies:
Re: Automation: Making package.mask better
-- Marius Mauch
Re: Automation: Making package.mask better
-- James Cloos
Re: Automation: Making package.mask better
-- Marijn Schouten (hkBst)
Re: Automation: Making package.mask better
-- Roy Bamford
Re: Automation: Making package.mask better
-- Robert Buchholz
Re: Automation: Making package.mask better
-- René 'Necoro' Neumann
Re: Automation: Making package.mask better
-- David Shakaryan
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Next by thread:
Re: Automation: Making package.mask better
Previous by date:
Re: Re: Improving developer/user communication
Next by date:
Re: Automation: Making package.mask better


Updated Jun 17, 2009

Summary: Archive of the gentoo-project mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.