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
1 On 7/23/07, Marius Mauch <genone@g.o> wrote:
2 > On Mon, 23 Jul 2007 10:55:15 -0700
3 > "Alec Warner" <antarus@g.o> wrote:
4 >
5 > > On 7/23/07, Marius Mauch <genone@g.o> wrote:
6 > > > On Sat, 21 Jul 2007 23:39:51 -0700
7 > > > "Alec Warner" <antarus@g.o> wrote:
8 > > >
9 > > > > I wish to add a few more fields:
10 > > > >
11 > > > > Effective-Date: Date the mask goes into effect. This means you
12 > > > > can mask stuff in the future.
13 > > > > Expiration-Date: Date the mask ends. This means you can have
14 > > > > masks that expire after a given time.
15 > > >
16 > > > No and no. I don't see a point in either of those, or since when is
17 > > > (absolute) time a relevant factor for masking status?
18 > > >
19 > > > > If Expiration-Date was mandatory, we could essentially have a
20 > > > > system that cleans out mask files by removing expired masks.
21 > > >
22 > > > Please provide use cases where a mask would expire at a given date
23 > > > and not based on the state of the tree (analog for Effective-Date).
24 > >
25 > > The best case is a last-rites mask. Given an Expiration-Date you can
26 > > alert on masks that are old (by data) as opposed to what we do now,
27 > > which is guess based on haphazard data in the mask and whether the
28 > > package is in the tree or not.
29 > >
30 > > Security masks are a subset of this and could benefit from an
31 > > expiration.
32 >
33 > How is it useful if a masked package suddenly becomes visible again?
34 >
35 > > We could drop the requirement of 'the package mangler expires masks
36 > > based on expiration' and just use the expiration by parsers so that
37 > > people can monitor masks and determine if/when stuff should happen.
38 >
39 > How about optional generic "reminder date" and "reminder purpose" fields
40 > then.
41 >
42
43 That seems to express the intent well, I'll bite ;)
44
45 > > > > Another thing I wish to address is the addition of entries in
46 > > > > package.mask at the top of the file. I think this restriction
47 > > > > just makes automation more difficult. I can't just append new
48 > > > > entries to the end of the file, I have to read in the file and
49 > > > > figure out by some hardcoded comment strings where the actaul
50 > > > > masks begin, and then insert text right below the examples. This
51 > > > > is horrible. Can we nuke that convention, why are new entries at
52 > > > > the top?
53 > > >
54 > > > I think that convention comes from the fact that package.mask also
55 > > > acts as a changelog for itself, and the newest entries are
56 > > > generally the more "interesting" ones.
57 > > >
58 > > > Marius
59 > >
60 > > So 'newer' correlates to 'more interesting'?
61 > > How does that mean 'new entries go at the top'?
62 >
63 > at the top => less scrolling when reading the file manually
64 > more interesting (newer) => read more often
65 >
66 > Mind that convention is from the days when portage didn't display
67 > actual masking status or the comments from package.mask, so people had
68 > to read package.mask manually if they wanted that information.
69 >
70 > Marius
71 >
72
73 Aha, see that makes lots of more sense with historical context...
74
75 Is there a reason to continue the trend? I am unaware of many tools
76 to write package.mask entries..although echangelog manages to put text
77 at the top of the changelog, I still think append is much easier ;)
78
79 -Alec
80 --
81 gentoo-project@g.o mailing list

Replies