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 D122059CA3 for ; Fri, 11 Mar 2016 02:31:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E91B9E086A; Fri, 11 Mar 2016 02:31:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D0D61E085C for ; Fri, 11 Mar 2016 02:31:04 +0000 (UTC) Received: from professor-x (S010634bdfa9ecf80.vc.shawcable.net [96.49.31.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id A7165340CD3 for ; Fri, 11 Mar 2016 02:31:03 +0000 (UTC) Date: Thu, 10 Mar 2016 18:30:07 -0800 From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree Message-ID: <20160310183007.027bb5f1.dolsen@gentoo.org> Organization: Gentoo Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 6c17a06e-1774-4b85-b7f5-b1bb1654f62d X-Archives-Hash: 9c71cb0ecb71bc8499d3ac5b0bca959f With the repoman rewrite stage2 code about to be merged into master. And a release including it to be made soon. I am going to start on stage3 of the rewrite. So... It is time to start painting a bikeshed about moving all possible check data to the tree. In that way small changes to things like the deprecated eclasses to scan for can be added to/or removed and the updates will propagate to everyone as they git pull the gentoo repo. So, here is my initial thoughts so far. We (portage team) discussed the possibility of making the data available for download via api.gentoo.org. But we decided it would be much better if that data was included in the repository. In that way it makes off-line work easier without having to deal with having a live connection to fetch the latest version of the data. It also then matches your current tree checkout. It could also make it easier for alternate repositories to establish their own QA data files. I'm thinking that we should establish a directory for the files containing the data for the checks being run. With the module systems now in place with the stage2 rewrite code. I was thinking that we should break up the data into logical files to go with the different scan modules present in repoman. If a new module is created, then a new data file may be created for it's dynamically changeable QA data. This also has the advantage that if a new app comes along that performs these same types of checks. It should be able to make use of this same data. So, where do we place this directory and what rules do we establish about it's modifications? location? : in the metadata dir alongside the install-qa-check.d directory? name of the directory? : repoman, qa-rules, qa-data, repo-qa-data, ... ideas? data format? : json (my favorite) compatible with many lanquages/interfaces is flexible to match various data types ie: dictionaries, lists, strings... is human readable/editable can be validated xml (PLEASE NO!) native python file (too language dependant) ini style (python configparser compatible) meh :/ other ideas? editing rules? : Similar to eclass modifications... email to the gentoo-dev list for review, possible objections. The current releases of portage/repoman would continue to use internal data. But this new data would need to precede a repoman release that uses it. Initially this stage3 code will continue to be developed in the repoman branch of the portage repo. It is also possible to test this git checkout code by establishing a symlink to the checkouts repoman command somewhere in your users PATH. Personally I named mine repom, and lives in my ~/bin directory. In that way I can easily switch between an installed repoman and the developing code to compare results to aid in debugging. -- Brian Dolbec