List Archive: gentoo-project
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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.
> firstname.lastname@example.org mailing list
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
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.
email@example.com mailing list