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: Steve Long <slong@...>
Subject: Re: Automation: Making package.mask better
Date: Mon, 23 Jul 2007 09:29:48 +0100
David Shakaryan wrote:
> Marijn Schouten (hkBst) wrote:
>> Can't we already (automatically) remove masks for which the relevant
>> ebuilds have been removed? Is there another situation for which you
>> think this is useful?
> 
> While it might be possible, we currently aren't doing that. It shouldn't
> be too difficult to implement, but it would have to be semi-smart and
> check if that package ever existed, as some developers add masks before
> adding packages and we don't want those automatically removed.
>
I thought a package removal was a slightly more complex thing than a simple 
dir removal? Even if it isn't, that's the point to tie in (ie when it's 
removed from the tree) imo.

> Without saying something on whether it would be useful or not, I think
> that we should change the format to sth which can be processed easily by
> programs (XML for instance). To ensure human readibility, one could keep
> the text file and have the xml one addtionally.
> 
> Then the whole process of adding fields is rather simple :)
> 
XML is much harder to process in scripts than plain-text. Having a simple
ini file format (eg [atom]), or a start and stop sequence (eg ## start
atom) is much easier both to read and to process. As for parsing, ini file 
format parsers and the like are common libs. There are two different libs for 
it in gentoo already[1] 

I agree that appending would be easier; it might also mean older masks don't
just get forgotten, since anyone looking at the file would have to scroll
past them, decreasing the likelihood of cruft.

I concur that the expiration date sounds risky (as another poster
described.) Personally I'd prefer all masks to have open bugs for as long
as they are in the file, assigned to the dev who made the entry. This would
be specific to the mask, and not any issues it is supposed to address
(which would be dependent bugs?)

Good luck with automation!

[1] http://article.gmane.org/gmane.linux.gentoo.devel/45762
-- 
gentoo-project@g.o mailing list


Navigation:
Lists: gentoo-project: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Automation: Making package.mask better
Next by thread:
Re: Improving developer/user communication
Previous by date:
Re: Automation: Making package.mask better
Next by date:
Re: Improving developer/user communication


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.