Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-project
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-project@g.o
From: Roy Bamford <neddyseagoon@g.o>
Subject: Re: Automation: Making package.mask better
Date: Sun, 22 Jul 2007 12:58:47 +0100
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


Replies:
Re: Automation: Making package.mask better
-- Vlastimil Babka
References:
Automation: Making package.mask better
-- Alec Warner
Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Automation: Making package.mask better
Next by thread:
Re: Automation: Making package.mask better
Previous by date:
Re: Automation: Making package.mask better
Next by date:
Re: Automation: Making package.mask better


Updated Jun 17, 2009

Summary: Archive of the gentoo-project mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.