-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/07/14 04:47 AM, Joshua Kinard wrote: > On 07/03/2014 03:00, Michael Haubenwallner wrote: >> >> 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/ > > That's the thing, make.profile technically *is* a directory -- a > symlink to one. The original design of make.profile was to specify > generic, base settings for a given profile and keep that in the > tree. Things like default CHOST, default ARCH, default <VARIABLE>, > etc. make.conf then overrides in-tree settings with settings > specific to your system. So making /etc/make.profile an actual > directory disconnects it from the tree, which I don't think will > work very well for Portage, since it won't know what your > currently-chosen profile is. >
I did a test where I dropped my make.profile symlink, made a directory of the same name, and populated a 'parent' file in that directory with paths to various /usr/portage/profiles/ bits which made up my previous main profile. Everything continued to work as expected. I expect for portage proper, we could accomodate mixins or whatever new structure method we want simply by adjusting 'eselect profile' to list the various possible combinations and adjust an /etc/make.profile/parent file accordingly. (We probably also need to ensure portage warns or errors appropriately when one of these inherit lines in the parent file no longer points to a directory, the same as it does now with the symlink points to nothing; I didn't test but I expect that error would not be pretty or easily understood right now) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlO1f4IACgkQ2ugaI38ACPB1wgEApznnssegz2ImYIq6fAeR2oGa RX0TNT6bThDcypkn0skA/j/w33cWekomOQanCKIspuOWxXgOAeMxMWlnhsORZfj7 =Qwj0 -----END PGP SIGNATURE-----
