Gentoo Archives: gentoo-dev

From: Roy Bamford <neddyseagoon@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Questions on overlays, repositories and PMS
Date: Sat, 24 Feb 2018 17:26:39
Message-Id: 3XX9asnRGxSGX0PEfaZ5ve@EXnwKtXhR0lz9w6RKZAxc
In Reply to: Re: [gentoo-dev] Questions on overlays, repositories and PMS by Michael Lienhardt
1 On 2018.02.24 01:32, Michael Lienhardt wrote:
2 >
3 >
4 > Il 23/02/2018 20:37, Alec Warner ha scritto:
5 > > My general observation is that Gentoo is not successful as an
6 > organization about deprecating and removing things. One area where
7 > Gentoo has done well is in EAPI and in PMS itself, with mostly-clear
8 > versioning and standards and whatnot. But in general if something
9 > worked 15 years ago, it probably still works today (doubly so for
10 > sys-apps/portage).
11 > >
12 > > There is a different question when building a tool like yours if it
13 > is worth the effort to support things that are 15 years old and are
14 > possibly not used (particularly in cases where functionality was
15 > replaced). I'd recommend starting with the basic implementation and
16 > adding support for the 'older' formats when users ask for them; but
17 > this is mostly a trade-off in efforts. If your goal is to build
18 > > a "100% compatible" tool then you will probably need to support
19 > these edge cases.
20 >
21 > You have a very good point.
22 > I'd like to be complete (it's a side effect of working in formal
23 > methods), but it's quite unrealistic as I am the only developer in
24 > this project, and it's true that there are few technical design
25 > choices that were made in portage that I'd be happier not to
26 > implement.
27 > I'd like to implement the /etc/portage/repos.conf system to remove as
28 > many hard coded references to /usr/portage in my code as possible.
29 > Moreover, the /etc/portage/repos.conf system looks nice, modular with
30 > explicit dependencies and it almost unifies all the repositories (I
31 > don't really understand the need of a DEFAULT section).
32 >
33 > If possible, I'd rather avoid implementing things that are deprecated,
34 > but like you pointed out, few are (portage seems to be always
35 > expanding with new/alternative functionalities).
36 > The ones that are, like the /etc/portage/package.keywords file, seem
37 > to be still used (I've got a request to support it in my
38 > get_installation.sh script).
39 > Additionally, there are two systems that I did not want to implement
40 > but had to: the IUSE_IMPLICIT and USE_EXPAND.
41 > I didn't find any good documentation on these systems (nor the PMS nor
42 > https://dev.gentoo.org/%7Ezmedico/portage/doc/man/portage.5.html are
43 > very clear on the subject -- the PMS is still clearer), I tested a lot
44 > and looked at the portage implementation...
45 > I don't understand the reason to implement these systems with bash
46 > variables expanded with prefixes, while many of the USE flag
47 > manipulation is done with dedicated files (use.*, package.use.*).
48 > It really felt like an old design choice kept there because it worked,
49 > but which could be simplified.
50 >
51 > On a similar topic, does anyone still have USE-related variables in
52 > his /etc/env.d folder? (https://wiki.gentoo.org/wiki/USE_ORDER)
53 > It seems to me that portage's current effort is to have all
54 > configuration files in /etc/portage or in the profile.
55 >
56 > Best,
57 > Michael Lienhardt
58 >
59 >
60 >
61 Michael,
62
63 'Support' can be as simple as nagging the user to move with the
64 times and failing.
65
66 I suspect that many older systems (including mine) are not updated
67 because it still works.
68
69 crossdev users may be familiar with this approach.
70
71 --
72 Regards,
73
74 Roy Bamford
75 (Neddyseagoon) a member of
76 elections
77 gentoo-ops
78 forum-mods