From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A85DE1382C5 for ; Thu, 1 Apr 2021 06:47:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2AD09E0AD0; Thu, 1 Apr 2021 06:47:41 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 93AD5E0A82 for ; Thu, 1 Apr 2021 06:47:40 +0000 (UTC) Date: Thu, 1 Apr 2021 00:47:34 -0600 From: Tim Harder To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] developing a separate repo spec Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Archives-Salt: 89aaec59-a931-4287-b1a7-44b6bd9220cb X-Archives-Hash: e196cb6378eaff72f2addb756a129bc1 On 2021-03-30 Tue 02:18, Ulrich Mueller wrote: > So yes, maybe we should have a separate spec for forward-compatible > repository features that are independent of EAPI. But I think that > incompatible changes won't be possible there and would have to reamin > in PMS. (For example, updating of package dependencies in profiles from > EAPI 0 to EAPI 5 was not forward compatible and required the one year > waiting period.) My main point is if users expect repos leveraging these features to work with most tools it would be helpful to document them in a more canonical, visible location than man pages and probably discuss them more visibly as well. If they were truly optional features it wouldn't be as much of an issue, but an increasing number of complex overlays assume a minimum of portage-1/portage-2 profile-formats features being readily available. Furthermore, I don't think the current spec even mentions the metadata/layout.conf file (and its semi-standard fields) and only passingly mentions overlays but has no details about them. Getting more of that in an official document would help devs know what they have to implement to support current repo/overlay functionality. Finally, pinning repo features to a standardized version allows tools to more readily report why they won't work when failing to meet the repo's required EAPI/RAPI instead of the semi-random errors that will often occur during unimplemented usage. Tim