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
On 7/23/07, Marius Mauch <email@example.com> wrote:
> On Mon, 23 Jul 2007 10:55:15 -0700
> "Alec Warner" <firstname.lastname@example.org> wrote:
> > On 7/23/07, Marius Mauch <email@example.com> wrote:
> > > On Sat, 21 Jul 2007 23:39:51 -0700
> > > "Alec Warner" <firstname.lastname@example.org> 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
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.
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 ;)
email@example.com mailing list