Gentoo Archives: gentoo-project

From: Roy Bamford <neddyseagoon@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Automation: Making package.mask better
Date: Sun, 22 Jul 2007 11:58:55
Message-Id: 1185105527l.7150l.0l@spike
In Reply to: [gentoo-project] Automation: Making package.mask better by Alec Warner
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.
> > -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


Subject Author
Re: [gentoo-project] Automation: Making package.mask better Vlastimil Babka <caster@g.o>