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 E97E61382C5 for ; Fri, 23 Feb 2018 19:37:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 583F1E0830; Fri, 23 Feb 2018 19:37:53 +0000 (UTC) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 E7FEEE07FA for ; Fri, 23 Feb 2018 19:37:52 +0000 (UTC) Received: by mail-ua0-x242.google.com with SMTP id n48so6530521uae.13 for ; Fri, 23 Feb 2018 11:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Gn6JZoZIDeKgeEJNxUY42dlU9+g225U46vEzVbqpkA8=; b=YV1d8NjqMJyD+E1YNRiqXL75CmgNbIcZiHGAR1zS2I5OoFmqHwplwsweFc6FAxAetW 9KPL5iOHWC7saOJ4y4Wz+trmVMHVN/SEaHuQXTm1VKr6tm6XN4rEW1NScZwGmgRvaIV0 ieyP9jRaewHmvnepLl1qmiDFzKnWZ8y/ZueMwPjY/eGe7YqfVY04Tn3y5w3JjFgIGaUb pgpuQZ3y0rtxlqQejmfsK10muSqVdT2FedxaSOUE0xAOZ0raXpkOrO+zufOkxuDOHG4v Lknxu3Xb6nOi+kcwCCIpBKyaIfPPu0bG2S0l3Bxc60kUQcofnMcspA23wzM7E1MWqAFd qJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Gn6JZoZIDeKgeEJNxUY42dlU9+g225U46vEzVbqpkA8=; b=gLOZ4DpIHHUevmdgcfbA4WTEy7fMJA7/MLZwqyACkRWPBjpgMb3hOLHgKbNuj1AEts 35OoobPlZazJpi9J4qMSMZJ+oRdOBshCB75DNIX0cYosybwm3QbFWnF97EG5RwKziq58 O4UX/u1bUllapZtnW6Mq4F729Xg7xHPOoBzEqtzXCPdZ+fhtdUGbResFCLJn9iFSQM27 kny1oHCtpE2kGsZ7LbT8QySvhN/NAy6Jt4DrBoYm700U6u+9js+IDJa18vTfn8qXZNW8 LgvdLsIzCLM0EglQpHohfO4lrQkaZEujhzOM1lKLXoi09u5JTp9unzRR4rT+ugz0r1/n V8TQ== X-Gm-Message-State: APf1xPDe8jKveTKFak4ojuFWgtDEkt0EeqSq3zi8SvcqUdUm5EmpQY8T IEuJxkGIOaEmQVLf/s3gAFfmh0wg/V50nmL8kCKR8Q== X-Google-Smtp-Source: AG47ELt8OdMn3pKCHmvKXLLwpD25xFPDUdO2vfiWjNrwGbPk30p7bzLFDMp5L53yD89BvGEN8hdih78EaC/dTf5Bj1k= X-Received: by 10.176.32.16 with SMTP id v16mr2162952uak.20.1519414671585; Fri, 23 Feb 2018 11:37:51 -0800 (PST) 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 Sender: antarus@scriptkitty.com Received: by 10.176.85.93 with HTTP; Fri, 23 Feb 2018 11:37:51 -0800 (PST) X-Originating-IP: [2620:0:1003:512:80ca:3f30:85e5:e774] In-Reply-To: <7390233c-9b93-d1be-2005-4f28b61e4289@laposte.net> References: <7390233c-9b93-d1be-2005-4f28b61e4289@laposte.net> From: Alec Warner Date: Fri, 23 Feb 2018 14:37:51 -0500 X-Google-Sender-Auth: ROZkd_p1ukL4hXexIa_kEbgLeqQ Message-ID: Subject: Re: [gentoo-dev] Questions on overlays, repositories and PMS To: Gentoo Dev Content-Type: multipart/alternative; boundary="f4030437d45cc44c030565e64bc0" X-Archives-Salt: 072d7d9b-ffed-43cd-8097-208b3811b506 X-Archives-Hash: be6d747a72a97dc16a7f676e697cb4a9 --f4030437d45cc44c030565e64bc0 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 23, 2018 at 12:36 PM, Michael Lienhardt < michael.lienhardt@laposte.net> wrote: > I started refactoring my solver to make it more modular, to fix some > details w.r.t. the PMS and to manage different repositories. > I thus have several questions on how multiple repositories work in portage. > > 1. My understanding was that /etc/portage/repos.conf replaced the > PORTDIR_OVERLAY variable, however this variable is still documented (e.g. > in https://devmanual.gentoo.org/general-concepts/overlay/index.html). > Was my intuition right? > Or in other word, it is enough to only look at /etc/portage/repos.conf? > In general, an overlay is a repository, i.e., a valid tree layout for the > PMS, right (as stated in https://devmanual.gentoo.org/g > eneral-concepts/overlay/index.html)? > > 2. the PMS states that any valid repository has a profiles folder which > can contain profiles and a package.mask file. > - can the profiles in a repository different from DEFAULT be selected? > - is the package.mask file apply only on the packages of that repository, > or on every packages of every repositories listed in > /etc/portage/repos.conf? > > 3. many repositories do not have an eclass folder, and miss many > (optional) configuration files in the profiles folder (like arch.list, > categories): > - is such information implicitly inherited from the DEFAULT repository > (even though https://wiki.gentoo.org/wiki//etc/portage/repos.conf states > that it is not)? > the brother overlay (https://github.com/stefan-lan > genmaier/brother-overlay) does not specify any masters > - when the eclass folder, profiles/arch.list and such are present, is the > data from the DEFAULT repository still implicitly inherited? > - when the eclass folder, profiles/arch.list and such are present, are > they visible globally (i.e., a package from another repository can use a > keyword of the arch.list and inherit from one of the eclass)? > > 4. is the "masters" attribute in /etc/portage/repos.conf make the > repository inherit other data than the eclasses? > > 5. since every repos can have a profiles/categories file, is the file > /etc/portage/categories obsolete (or should it be)? > > My general observation is that Gentoo is not successful as an organization about deprecating and removing things. One area where Gentoo has done well is in EAPI and in PMS itself, with mostly-clear versioning and standards and whatnot. But in general if something worked 15 years ago, it probably still works today (doubly so for sys-apps/portage). There is a different question when building a tool like yours if it is worth the effort to support things that are 15 years old and are possibly not used (particularly in cases where functionality was replaced). I'd recommend starting with the basic implementation and adding support for the 'older' formats when users ask for them; but this is mostly a trade-off in efforts. If your goal is to build a "100% compatible" tool then you will probably need to support these edge cases. -A > > Best Regards, > Michael Lienhardt > > > --f4030437d45cc44c030565e64bc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 23, 2018 at 12:36 PM, Michael Lienhardt &= lt;micha= el.lienhardt@laposte.net> wrote:
I started refactoring my solver to make it more modular, to fix some = details w.r.t. the PMS and to manage different repositories.
I thus have several questions on how multiple repositories work in portage.=

1. My understanding was that /etc/portage/repos.conf replaced the PORTDIR_O= VERLAY variable, however this variable is still documented (e.g. in https://devmanual.gentoo.org/general= -concepts/overlay/index.html).
Was my intuition right?
Or in other word, it is enough to only look at /etc/portage/repos.conf?
In general, an overlay is a repository, i.e., a valid tree layout for the P= MS, right (as stated in https://devm= anual.gentoo.org/general-concepts/overlay/index.html)?

2. the PMS states that any valid repository has a profiles folder which can= contain profiles and a package.mask file.
=C2=A0- can the profiles in a repository different from DEFAULT be selected= ?
=C2=A0- is the package.mask file apply only on the packages of that reposit= ory, or on every packages of every repositories listed in /etc/portage/repo= s.conf?

3. many repositories do not have an eclass folder, and miss many (optional)= configuration files in the profiles folder (like arch.list, categories): =C2=A0- is such information implicitly inherited from the DEFAULT repositor= y (even though https://wiki.gentoo.org/wiki//etc/portage/repos.conf states that it is not)?
=C2=A0 =C2=A0 =C2=A0the brother overlay (https:= //github.com/stefan-langenmaier/brother-overlay) does not specify = any masters
=C2=A0- when the eclass folder, profiles/arch.list and such are present, is= the data from the DEFAULT repository still implicitly inherited?
=C2=A0- when the eclass folder, profiles/arch.list and such are present, ar= e they visible globally (i.e., a package from another repository can use a = keyword of the arch.list and inherit from one of the eclass)?

4. is the "masters" attribute in /etc/portage/repos.conf make the= repository inherit other data than the eclasses?

5. since every repos can have a profiles/categories file, is the file /etc/= portage/categories obsolete (or should it be)?


My general observation is that Gentoo = is not successful as an organization about deprecating and removing things.= One area where Gentoo has done well is in EAPI and in PMS itself, with mos= tly-clear versioning and standards and whatnot. But in general if something= worked 15 years ago, it probably still works today (doubly so for sys-apps= /portage).

There is a different question when buil= ding a tool like yours if it is worth the effort to support things that are= 15 years old and are possibly not used (particularly in cases where functi= onality was replaced). I'd recommend starting with the basic implementa= tion and adding support for the 'older' formats when users ask for = them; but this is mostly a trade-off in efforts. If your goal is to build a= "100% compatible" tool then you will probably need to support th= ese edge cases.

-A
=C2=A0

Best Regards,
Michael Lienhardt



--f4030437d45cc44c030565e64bc0--