1 |
On Fri, Feb 23, 2018 at 12:36 PM, Michael Lienhardt < |
2 |
michael.lienhardt@×××××××.net> wrote: |
3 |
|
4 |
> I started refactoring my solver to make it more modular, to fix some |
5 |
> details w.r.t. the PMS and to manage different repositories. |
6 |
> I thus have several questions on how multiple repositories work in portage. |
7 |
> |
8 |
> 1. My understanding was that /etc/portage/repos.conf replaced the |
9 |
> PORTDIR_OVERLAY variable, however this variable is still documented (e.g. |
10 |
> in https://devmanual.gentoo.org/general-concepts/overlay/index.html). |
11 |
> Was my intuition right? |
12 |
> Or in other word, it is enough to only look at /etc/portage/repos.conf? |
13 |
> In general, an overlay is a repository, i.e., a valid tree layout for the |
14 |
> PMS, right (as stated in https://devmanual.gentoo.org/g |
15 |
> eneral-concepts/overlay/index.html)? |
16 |
> |
17 |
> 2. the PMS states that any valid repository has a profiles folder which |
18 |
> can contain profiles and a package.mask file. |
19 |
> - can the profiles in a repository different from DEFAULT be selected? |
20 |
> - is the package.mask file apply only on the packages of that repository, |
21 |
> or on every packages of every repositories listed in |
22 |
> /etc/portage/repos.conf? |
23 |
> |
24 |
> 3. many repositories do not have an eclass folder, and miss many |
25 |
> (optional) configuration files in the profiles folder (like arch.list, |
26 |
> categories): |
27 |
> - is such information implicitly inherited from the DEFAULT repository |
28 |
> (even though https://wiki.gentoo.org/wiki//etc/portage/repos.conf states |
29 |
> that it is not)? |
30 |
> the brother overlay (https://github.com/stefan-lan |
31 |
> genmaier/brother-overlay) does not specify any masters |
32 |
> - when the eclass folder, profiles/arch.list and such are present, is the |
33 |
> data from the DEFAULT repository still implicitly inherited? |
34 |
> - when the eclass folder, profiles/arch.list and such are present, are |
35 |
> they visible globally (i.e., a package from another repository can use a |
36 |
> keyword of the arch.list and inherit from one of the eclass)? |
37 |
> |
38 |
> 4. is the "masters" attribute in /etc/portage/repos.conf make the |
39 |
> repository inherit other data than the eclasses? |
40 |
> |
41 |
> 5. since every repos can have a profiles/categories file, is the file |
42 |
> /etc/portage/categories obsolete (or should it be)? |
43 |
> |
44 |
> |
45 |
My general observation is that Gentoo is not successful as an organization |
46 |
about deprecating and removing things. One area where Gentoo has done well |
47 |
is in EAPI and in PMS itself, with mostly-clear versioning and standards |
48 |
and whatnot. But in general if something worked 15 years ago, it probably |
49 |
still works today (doubly so for sys-apps/portage). |
50 |
|
51 |
There is a different question when building a tool like yours if it is |
52 |
worth the effort to support things that are 15 years old and are possibly |
53 |
not used (particularly in cases where functionality was replaced). I'd |
54 |
recommend starting with the basic implementation and adding support for the |
55 |
'older' formats when users ask for them; but this is mostly a trade-off in |
56 |
efforts. If your goal is to build a "100% compatible" tool then you will |
57 |
probably need to support these edge cases. |
58 |
|
59 |
-A |
60 |
|
61 |
|
62 |
> |
63 |
> Best Regards, |
64 |
> Michael Lienhardt |
65 |
> |
66 |
> |
67 |
> |