| 1 |
On 07/03/2014 08:18 AM, Joshua Kinard wrote: |
| 2 |
> On 07/02/2014 13:54, Michał Górny wrote: |
| 3 |
>> Dnia 2014-07-02, o godz. 10:44:16 |
| 4 |
> [snip] |
| 5 |
>> |
| 6 |
>> I don't feel like we ought to vote on something like this without |
| 7 |
>> understanding most of the current profiles. And I'm afraid there are |
| 8 |
>> only few people who have any idea about the current profile |
| 9 |
>> structure... |
| 10 |
>> |
| 11 |
> |
| 12 |
> I am going to throw this out there and see what people think. Maybe it's |
| 13 |
> insane, maybe it's not, maybe it's a mix of insane and not-insane. |
| 14 |
> |
| 15 |
> Years ago, before we had the current stacking profile design (we were |
| 16 |
> discussing the current design, actually), I kinda conjured up this "building |
| 17 |
> blocks" like approach for a profile design. |
| 18 |
|
| 19 |
> The idea being that, in /etc/make.conf (or wherever that file is now), you'd |
| 20 |
> define $PROFILE like this: |
| 21 |
> |
| 22 |
> linux-mips o32 uclibc server: |
| 23 |
> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" |
| 24 |
|
| 25 |
What about making /etc/portage/make.profile a directory rather than a symlink, |
| 26 |
having /etc/portage/make.profile/parent to reference all the flavours? |
| 27 |
|
| 28 |
Tools that need to respect the /current/ profile should work without any change, and |
| 29 |
tools that need to respect the /available/ profiles (repoman) already do have a list |
| 30 |
of profiles to respect (profiles/profiles.desc). |
| 31 |
|
| 32 |
So the only missing thing would be the eselect profile module to manage entries of |
| 33 |
/etc/portage/make.profile/parent, maybe using /usr/portage/profiles/profiles.desc |
| 34 |
as the source for available flavours. |
| 35 |
|
| 36 |
my 2 cents |
| 37 |
/haubi/ |
Archives