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 190D41388BF for ; Sun, 10 Jan 2016 21:41:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7368721C008; Sun, 10 Jan 2016 21:40:59 +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 9AE1021C002 for ; Sun, 10 Jan 2016 21:40:58 +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 C056834085D for ; Sun, 10 Jan 2016 21:40:57 +0000 (UTC) Date: Sun, 10 Jan 2016 13:40:08 -0800 From: Brian Dolbec To: gentoo-portage-dev@lists.gentoo.org Subject: [gentoo-portage-dev] [Patch] Repoman rewrite stage2 modularization conversion complete Message-ID: <20160110134008.4fce78c0.dolsen@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: ae514c2b-4ff8-46e2-9af2-9a5ba6629066 X-Archives-Hash: 7d80c3555bb7d78f71a96bbab50059a7 I have now pushed a fully rebased, properly sequenced commit history to the repoman branch. To be honest I think all the rebasing, re-testing took as much time as the initial conversion and testing. Anyway, I consider the branch now ready for final review. Since there are a total of 45 commits. I am not sending them to the list at this time. They are available for review via the repoman branch at https://gitweb.gentoo.org/proj/portage.git/log/?h=repoman https://github.com/gentoo/portage/commits/repoman or github pull request for commit order convienience https://github.com/gentoo/portage/pull/22 But please try to follow our standard rules and reply with any comments or code review to this email thread. I can also generate the email patches if necessary, but I fear they will just clog up your inbox. There are some patches that are quite large like the vcs plug-in conversion which could not be done piecemeal and still be able to run the code to test. Summary: This stage now has three plugin system loops to process all the checks and maintenance actions. The three loops are currently hard-coded and many of the checks must be run in a certain order as many of the checks add or modify the dynamic data required by later checks. I will endeavour to create a complete wiki page on the new system when approved, detailing how to create modules. I will also generate a table of dynamic data available and the modules responsible for it. In that way any modification to the modules run, added or removed can be determined. 1) Primary pkg level checks 2) Ebuild level checks 3) Final pkg level summary checks There are 2 primary plugin systems 1) The VCS plugin system 2) The Scan plugin system All use the existing portage plugin system used in emaint and the new sysnc systems. The scan plugin modules can have functions that run in any of the three loops. They can also have more that one function that runs in any one loop. All functions in the loop will be run in sequence in the order listed. The plugin system runs the functions via reference, not name, so the module lists the functions by reference. The runInPkgs, runInEbuild and runInFinal functions are designed in a way that allow for the most flexibility and control by the module itself. As such one loop level function can control the actions of the next levels. They are not forced to be hard-coded. Although, there are currently no modules that use or need that ability at this time. Still to do in further rewites: Create a file or files to store easily edited repository data that can be included in the repo metadata. In that way small changes can be done by maintainers without requiring a new repoman release because that data comes with the release. Make the plug-in checks loops configurable. Then the checks run can be configured for the repo being checked. All repos are not created equal and may have their own eclasses and eclass checks, etc.. Continued code optimizations. At this point many of the scan checks, etc. have not undergone extensive changes. Only what was necessary to fit the new structure. Many could probably be optimised for better configure-ability and execution. -- Brian Dolbec