Re: [gentoo-dev] new profile layout with flavors and mix-ins

[Ian Stakenvicius <axs@gentoo.org>]

-----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-----