1 |
On 2007.07.22 07:39, Alec Warner wrote: |
2 |
> My goal here is to improve the speed at which developers work and |
3 |
> making it easier to do things, hence the 'automation' series of mails |
4 |
> (of which this is the first of hopefully many). |
5 |
> |
6 |
> Todays subject is package.mask. |
7 |
> |
8 |
> Package.mask is a file read by both the package mangler and humans to |
9 |
> determine if a given CP(V) is masked or not, and also to try and |
10 |
> determine who did the masking, when, and why. |
11 |
|
12 |
[snip] |
13 |
|
14 |
> |
15 |
> -Alec |
16 |
> -- |
17 |
> gentoo-project@g.o mailing list |
18 |
> |
19 |
> |
20 |
|
21 |
Alec, |
22 |
|
23 |
Standardisation is a good thing, it certainly aids automation, so I |
24 |
don't have an issue with defining any fields you like. The automatic |
25 |
use of dates I can see a problem with. |
26 |
|
27 |
Packages are masked for three reasons |
28 |
1. At the beginning of life. They are not yet ready for everyday use. |
29 |
2. They were released and now there is a major bug. |
30 |
3. At end of life, before they are removed. |
31 |
|
32 |
All of these scenarios need something else to happen manually before |
33 |
the future date is reached. Some examples may be better. |
34 |
|
35 |
1. Lets say I'm waiting for KDE 5 and I have ebuilds in my tree masked |
36 |
with future dates set. I'm so keen to get it, the date arrives and I do |
37 |
emerge kde-meta |
38 |
Hopefully, the ebuilds I have are still not keyworded, so nothing nasty |
39 |
happens. I do emerge --sync and get updated ebuilds and an updated |
40 |
package.mask with new (later) future dates. No harm done. |
41 |
What if the packages were already keyworded ? |
42 |
|
43 |
2 and 3 are pretty much the same. |
44 |
They depend on a fix or package removal happening before the future |
45 |
date is reached. We all know that fixes take as long as they take. |
46 |
For removals, the removal process would need to be automated using the |
47 |
same or an earlier date. |
48 |
|
49 |
I do see one way round these complications though. |
50 |
Force an emerge --sync |
51 |
of package.mask and the affected ebuilds before implementing any date |
52 |
released features. After all, future dates represent plans, its as well |
53 |
to check the plan worked before acting on it. |
54 |
|
55 |
Regards, |
56 |
|
57 |
Roy Bamford |
58 |
(NeddySeagoon) |
59 |
|
60 |
-- |
61 |
gentoo-project@g.o mailing list |