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 |