Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] Support override of default profile EAPI (532670)
Date: Mon, 22 Dec 2014 18:34:03
Message-Id: 54986418.1070903@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH] Support override of default profile EAPI (532670) by Alexander Berntsen
1 On 12/22/2014 04:59 AM, Alexander Berntsen wrote:
2 > The idea presented in the commit message header is very good. The
3 > implementation discussed in the commit message body sounds a bit
4 > messy, but I can't immediately think of another way to support this.
5
6 Given existing state of the code, I think my implementation is quite
7 reasonable. It's seems a bit messy because the functions/methods
8 involved need to deal with 3 different kinds of profile nodes:
9
10 1) Regular profile nodes
11
12 2) User profile override directory in /etc/portage/profile
13
14 3) The root "profiles" directory, which is not really a profile node,
15 but is used for repository-level configurations (package.mask being the
16 most common example used by Gentoo)
17
18 I will add a note about this to the commit message, since it's not
19 completely obvious unless you have had to dive into this code for some
20 reason.
21
22 > Can you? Can anyone else?
23
24 No, not without making extensive changes to the existing code (probably
25 without much payoff). However, the changes that I've made do produce the
26 intended result, and they make the existing code more flexible by making
27 it possible to override the repository-level default. My changes also
28 significantly reduce the number of read_corresponding_eapi_file calls,
29 which seems more organized because this way a given node's EAPI only
30 needs to be determined once rather than through repeated (memoized)
31 calls to read_corresponding_eapi_file.
32
33 > I'd like to have more of a discussion before this is merged.
34
35 Yeah, it's good to have others check my work, because there are lots of
36 opportunities for small logic errors here. However, I'm confident that
37 the current patch is bug-free, since I have tested many different
38 scenarios by tweaking values in the unit test.
39
40 > The patch itself looks OK though.
41
42 Great, thanks for your feedback!
43 --
44 Thanks,
45 Zac

Replies