From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 426611388B6 for ; Tue, 5 Jan 2016 03:18:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9BC30E0857; Tue, 5 Jan 2016 03:18:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9CD53E0851 for ; Tue, 5 Jan 2016 03:18:32 +0000 (UTC) Received: from professor-x (S010634bdfa9ecf80.vc.shawcable.net [96.49.31.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 9A29F34069F for ; Tue, 5 Jan 2016 03:18:31 +0000 (UTC) Date: Mon, 4 Jan 2016 19:17:41 -0800 From: Brian Dolbec To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages Message-ID: <20160104191741.0cc3c8a3.dolsen@gentoo.org> In-Reply-To: <1451943030-20380-1-git-send-email-vapier@gentoo.org> References: <1451943030-20380-1-git-send-email-vapier@gentoo.org> Organization: Gentoo Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: f0b98bb8-e870-4dbc-81d7-3c7891c69295 X-Archives-Hash: ff285fe025c8faf04f5ca9575f7f1a60 On Mon, 4 Jan 2016 16:30:30 -0500 Mike Frysinger wrote: > Some packages list the same atom multiple times (e.g. behind diff USE > flags). If one of them throws an error, we end up listing it more > than once, and the output can get verbose/useless. > --- > pym/repoman/scanner.py | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/pym/repoman/scanner.py b/pym/repoman/scanner.py > index d1c10d7..94ada90 100644 > --- a/pym/repoman/scanner.py > +++ b/pym/repoman/scanner.py > @@ -704,13 +704,22 @@ class Scanner(object): > > # we > have some unsolvable deps # remove ! deps, which always show up as > unsatisfiable > - > atoms = [ > + > all_atoms = [ str(atom.unevaluated_atom) > for > atom in atoms if not atom.blocker] > # if > we emptied out our list, continue: > - if > not atoms: > + if > not all_atoms: continue > + > + # > Filter out duplicates. We do this by hand (rather > + # > than use a set) so the order is stable and better > + # > matches the order that's in the ebuild itself. > + > atoms = [] > + for > atom in all_atoms: > + > if atom not in atoms: > + > atoms.append(atom) + > if > self.options.output_style in ['column']: > self.qatracker.add_error(mykey, "%s: %s: %s(%s) %s" I immediately want to say REJECT!, REJECT!, REJECT!,... I just spent a marathon week working on stage2 of the repoman rewrite. I have all the checks and vcs related code in 2 plugin systems. I have to move the vcs plugins to their final destination path still (minor move) I am going to start cleaning up the commits, do some rebasing and unifying of them all now that I have it split up and working. Still some more testing/debugging to do. Hopefully be the end of this week it'll be ready for review and merge soon. If this is applied to current repoman, it may cause some rebase hell. https://github.com/dol-sen/portage/tree/repoman That is the repoman branch with the individualized checks that run in 3 small loops in scanner.py now. There is no code in scanner that does any checks. Those are all in pym/repoman/modules/scan/*/*.py. Some modules contain several different files and class definitions. There are a bunch of new ones that I created from the code that still remained in scanner.py's _scan_ebuilds(). I'll push the changes to teh main gentoo portage repo's repoman branch once I have it cleaned up. I would much prefer you re-base your patch on the rewrite code. I will make a wiki page for the module definition requirements, with a section on the vcs system as well. But the modules are quite simple, only small changes from the initial code split we did already. So new modules are easy to create and add in to the sequence of checks to perform. You just have to be careful where you insert checks. As the dynamic_data used and updated by the modules varies as it progresses through the sequence. I have yet to document the data changed/required by each of the modules. But they are quite clear looking at the code. -- Brian Dolbec