On Wednesday 25 January 2006 20:46, Brian Harring wrote:
> On Wed, Jan 25, 2006 at 08:27:22PM +0900, Jason Stubbs wrote:
> > On Wednesday 25 January 2006 18:10, Donnie Berkholz wrote:
> > > Jason Stubbs wrote:
> > > > DEPEND="x11-base/xorg-x11"              # wrong
> > > > DEPEND="virtual/x11"                    # wrong
> > > > DEPEND="|| ( x11? ( virtual/x11 ) )"    # wrong
> > > > DEPEND="|| ( misc/atoms virtual/x11 )"  # right
> > > > 
> > > > There's a small possibility that broken packages will be missed by 
> > > > this, but is there any chance that valid packages will be incorrectly 
> > > > flagged? If this gets a go-ahead, it'll be easy enough to get in for 
> > > > the next release (which is likely this coming Saturday).
> > > 
> > > It sounds right. There should be no valid instance of virtual/x11 that
> > > is not within an || dep.
> > 
> > I've implemented and tested the check locally but haven't committed it 
> > yet. Repoman isn't really structured to allow for tests against a set of 
> > ebuilds so the checks are done on every version. There is also definitely 
> > one false positive (virtual/x11-6.8) so, for this and the fact that every 
> > version is tested, it would probably better to just make it a warning. 
> > Thoughts? 
> 
> Curious about the mechanism you're using for this... a hardcoded set 
> of atoms in repoman doesn't sound very nice to me ;)

Get off it. There's no other way to do it given repoman's state and the 
requirements. If you'd like to make repoman pluggable, convert all the 
current checks to plugins and then make a new plugin for this one and do it 
all by this weekend, be my guest. :P

Besides, what's wrong with hardcoded atoms in repoman anyway? Repoman doesn't 
have to stand the test of time. Conversely, it should represent checks for 
whatever issues are present in the tree at the time of its release.

http://dev.gentoo.org/~jstubbs/x11_deprecation_check.diff

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Reply via email to