| 1 |
Did you mean env/ files ? Having a different behaviour for |
| 2 |
/etc/portage/package.env and $profile/package.env would be confusing. |
| 3 |
|
| 4 |
Parsing env/ atom/files association in python would be a good idea. We |
| 5 |
should get the benefits of both I believe. |
| 6 |
The list of files to be sourced by bash could contain all the files |
| 7 |
relevant to the package in one profile then profile.bashrc, for each |
| 8 |
profile so that |
| 9 |
we don't even need to walk all the profiles in ebuild.sh. |
| 10 |
|
| 11 |
Bertrand |
| 12 |
|
| 13 |
On Mon, Sep 22, 2014 at 11:24 AM, Zac Medico <zmedico@g.o> wrote: |
| 14 |
|
| 15 |
> On 09/22/2014 11:16 AM, Zac Medico wrote: |
| 16 |
> > On 09/22/2014 09:16 AM, Bertrand Simonnet wrote: |
| 17 |
> >> Zac, Michal, |
| 18 |
> >> |
| 19 |
> >> Would you be willing to merge this ? |
| 20 |
> >> If env/ instead of package.env is a deal breaker, I can change that. |
| 21 |
> >> A bashrc like mechanism is more practical for us but package.env will do |
| 22 |
> >> the trick too |
| 23 |
> >> and we really want to have this in mainline portage. |
| 24 |
> >> |
| 25 |
> >> Thanks, |
| 26 |
> >> Bertrand |
| 27 |
> > |
| 28 |
> > In order to solve Michał's concern about the "hardcoded list of atoms", |
| 29 |
> > we might choose this slightly different approach: |
| 30 |
> > |
| 31 |
> > In python, parse package.env atom/file associations from the profile, |
| 32 |
> > and pass the associated file names to bash as array, so that those files |
| 33 |
> > can be sourced by bash. |
| 34 |
> > |
| 35 |
> > Thoughts? |
| 36 |
> > |
| 37 |
> |
| 38 |
> Also, note that with this hybrid bashrc like approach, you still won't |
| 39 |
> be able to adjust FEATURES. However, I'm not so sure that per-package |
| 40 |
> FEATURES adjustment is really that useful at the profile level. |
| 41 |
> -- |
| 42 |
> Thanks, |
| 43 |
> Zac |
| 44 |
> |
| 45 |
> |
Archives