Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: Marius Mauch <genone@g.o>, gentoo-project@l.g.o
Subject: Re: [gentoo-project] Automation: Making package.mask better
Date: Tue, 24 Jul 2007 02:55:00
Message-Id: b41005390707231954o17f0d398w7b896aa72d175f9a@mail.gmail.com
On 7/23/07, Marius Mauch <genone@g.o> wrote:
> On Mon, 23 Jul 2007 10:55:15 -0700 > "Alec Warner" <antarus@g.o> wrote: > > > On 7/23/07, Marius Mauch <genone@g.o> wrote: > > > On Sat, 21 Jul 2007 23:39:51 -0700 > > > "Alec Warner" <antarus@g.o> wrote: > > > > > > > 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. > > > > > > No and no. I don't see a point in either of those, or since when is > > > (absolute) time a relevant factor for masking status? > > > > > > > If Expiration-Date was mandatory, we could essentially have a > > > > system that cleans out mask files by removing expired masks. > > > > > > Please provide use cases where a mask would expire at a given date > > > and not based on the state of the tree (analog for Effective-Date). > > > > The best case is a last-rites mask. Given an Expiration-Date you can > > alert on masks that are old (by data) as opposed to what we do now, > > which is guess based on haphazard data in the mask and whether the > > package is in the tree or not. > > > > Security masks are a subset of this and could benefit from an > > expiration. > > How is it useful if a masked package suddenly becomes visible again? > > > We could drop the requirement of 'the package mangler expires masks > > based on expiration' and just use the expiration by parsers so that > > people can monitor masks and determine if/when stuff should happen. > > How about optional generic "reminder date" and "reminder purpose" fields > then. >
That seems to express the intent well, I'll bite ;)
> > > > 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? > > > > > > I think that convention comes from the fact that package.mask also > > > acts as a changelog for itself, and the newest entries are > > > generally the more "interesting" ones. > > > > > > Marius > > > > So 'newer' correlates to 'more interesting'? > > How does that mean 'new entries go at the top'? > > at the top => less scrolling when reading the file manually > more interesting (newer) => read more often > > Mind that convention is from the days when portage didn't display > actual masking status or the comments from package.mask, so people had > to read package.mask manually if they wanted that information. > > Marius >
Aha, see that makes lots of more sense with historical context... Is there a reason to continue the trend? I am unaware of many tools to write package.mask entries..although echangelog manages to put text at the top of the changelog, I still think append is much easier ;) -Alec -- gentoo-project@g.o mailing list

Replies