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 21CDD59CA3 for ; Fri, 11 Mar 2016 18:36:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C81E421C063; Fri, 11 Mar 2016 18:36:27 +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 CDD1321C051 for ; Fri, 11 Mar 2016 18:36:26 +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 C5E4D34072E for ; Fri, 11 Mar 2016 18:36:25 +0000 (UTC) Date: Fri, 11 Mar 2016 10:35:29 -0800 From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree Message-ID: <20160311103529.64300173.dolsen@gentoo.org> In-Reply-To: <20160310184031.4c9dd658@gentoo.org> References: <20160310183007.027bb5f1.dolsen@gentoo.org> <20160310184031.4c9dd658@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: 84057f28-2358-43bc-87ad-840776a2d2e3 X-Archives-Hash: 354fbf8d733c98f0c73d863bc4b8229e On Thu, 10 Mar 2016 18:40:31 -0800 Patrick McLean wrote: > On Thu, 10 Mar 2016 18:30:07 -0800 > Brian Dolbec wrote: > > > 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? > > That sounds reasonable to me, it is certainly metadata. > > > > > name of the directory? : repoman, qa-rules, qa-data, > > repo-qa-data, ... ideas? > > Something not project name specific, so nothing about repoman. Perhaps > something like "repo-checks", my personal vote would be make it a > directory with the contents being merged (so repo-checks.d maybe?) > > > > > 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? > > YAML - like JSON but made to be edited/read by humans (comment support > is a big feature). Also valid JSON is valid YAML. Also can be > validated just like JSON can. OK, I just had a closer look at yaml. It does look easier for humans to edit and read. And seems to have the same data type flexibility. Maybe not quite as many languages have libs for it. But I don't think that is an issue for this data. I also want to separate the repoman release from the main portage release. This will have several advantages. 1) smaller portage install for installs that don't need repoman capabilities. 2) Repoman can add extra dependencies as needed for things like pyyaml and xmlschema. These deps would not be required for the base portage/emerge code. Keeping a base install stage3 lighter and not complicate bootstrapping a stage1, stage2. 3) They can be released indendant of each other as the need for a new release is desired/required. While repoman will still be tied to the portage codebase. Most of it's code use is via fairly stable API's. So only when those API's change will there need to be a simultaneos release. -- Brian Dolbec