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 |