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