On 2007.07.22 07:39, Alec Warner wrote:
> My goal here is to improve the speed at which developers work and
> making it easier to do things, hence the 'automation' series of mails
> (of which this is the first of hopefully many).
> 
> Todays subject is package.mask.
> 
> Package.mask is a file read by both the package mangler and humans to
> determine if a given CP(V) is masked or not, and also to try and
> determine who did the masking, when, and why.

[snip]

> 
> -Alec
> -- 
> gentoo-project@g.o mailing list
> 
> 

Alec,

Standardisation is a good thing, it certainly aids automation, so I 
don't have an issue with defining any fields you like. The automatic 
use of dates I can see a problem with.

Packages are masked for three reasons
1. At the beginning of life. They are not yet ready for everyday use.
2. They were released and now there is a major bug.
3. At end of life, before they are removed.

All of these scenarios need something else to happen manually before 
the future date is reached. Some examples may be better.

1. Lets say I'm waiting for KDE 5 and I have ebuilds in my tree masked 
with future dates set. I'm so keen to get it, the date arrives and I do 
emerge kde-meta
Hopefully, the ebuilds I have are still not keyworded, so nothing nasty 
happens. I do emerge --sync and get updated ebuilds and an updated 
package.mask with new (later) future dates. No harm done.
What if the packages were already keyworded ?

2 and 3 are pretty much the same.
They depend on a fix or package removal happening before the future 
date is reached. We all know that fixes take as long as they take.
For removals, the removal process would need to be automated using the 
same or an earlier date.

I do see one way round these complications though. 
Force an emerge --sync 
of package.mask and the affected ebuilds before implementing any date 
released features. After all, future dates represent plans, its as well 
to check the plan worked before acting on it.

Regards,

Roy Bamford
(NeddySeagoon) 

--
gentoo-project@g.o mailing list