| 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 |
Archives