Michal, not opposed to splitting the patch into three parts. I'd rather use the env/ mechanism instead of the package.env one as it is more flexible. It also feels better as ebuild.sh will walk the profiles to source the bashrc script so a bashrc from a "low priority" profile may override a package.env definition from a high priority profile.
I'll remove the with spaces and the Change-Id (gerrit specific tag I believe) Bertrand On Wed, Sep 17, 2014 at 2:43 PM, Zac Medico <zmed...@gentoo.org> wrote: > On 09/17/2014 02:28 PM, Michał Górny wrote: > >> diff --git a/pym/portage/repository/config.py > b/pym/portage/repository/config.py > >> index 5e0d055..ef8054e 100644 > >> --- a/pym/portage/repository/config.py > >> +++ b/pym/portage/repository/config.py > >> @@ -40,7 +40,7 @@ if sys.hexversion >= 0x3000000: > >> _invalid_path_char_re = re.compile(r'[^a-zA-Z0-9._\-+:/]') > >> > >> _valid_profile_formats = frozenset( > >> - ['pms', 'portage-1', 'portage-2']) > >> + ['pms', 'portage-1', 'portage-2', 'profile-env']) > > > > I'm not sure if dedicated profile format is the best way to go. If I > > understand your patch correctly, this means that 'profile-env' has only > > features of PMS profile but not of 'portage-*' formats. This could mean > > that some people would have to choose between features of one or > > the other. Since both are compatible, i suggest 'portage-3' instead. > > The profile-formats field is designed to allow mixing of formats. So, > it's legal to mix profile-env with any of the other formats. > -- > Thanks, > Zac > >
