On Fri, Feb 23, 2018 at 12:36 PM, Michael Lienhardt < michael.lienha...@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 > > >
