1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 03/07/14 04:47 AM, Joshua Kinard wrote: |
5 |
> On 07/03/2014 03:00, Michael Haubenwallner wrote: |
6 |
>> |
7 |
>> On 07/03/2014 08:18 AM, Joshua Kinard wrote: |
8 |
>>> On 07/02/2014 13:54, Michał Górny wrote: |
9 |
>>>> Dnia 2014-07-02, o godz. 10:44:16 |
10 |
>>> [snip] |
11 |
>>>> |
12 |
>>>> I don't feel like we ought to vote on something like this |
13 |
>>>> without understanding most of the current profiles. And I'm |
14 |
>>>> afraid there are only few people who have any idea about the |
15 |
>>>> current profile structure... |
16 |
>>>> |
17 |
>>> |
18 |
>>> I am going to throw this out there and see what people think. |
19 |
>>> Maybe it's insane, maybe it's not, maybe it's a mix of insane |
20 |
>>> and not-insane. |
21 |
>>> |
22 |
>>> Years ago, before we had the current stacking profile design |
23 |
>>> (we were discussing the current design, actually), I kinda |
24 |
>>> conjured up this "building blocks" like approach for a profile |
25 |
>>> design. |
26 |
>> |
27 |
>>> The idea being that, in /etc/make.conf (or wherever that file |
28 |
>>> is now), you'd define $PROFILE like this: |
29 |
>>> |
30 |
>>> linux-mips o32 uclibc server: |
31 |
>>> PROFILE="base:kernel/linux:arch/mips:subarch/mips-o32:libc/uclibc:roles/server:releases/13.0" |
32 |
>> |
33 |
>> |
34 |
>>> |
35 |
What about making /etc/portage/make.profile a directory rather than a |
36 |
symlink, |
37 |
>> having /etc/portage/make.profile/parent to reference all the |
38 |
>> flavours? |
39 |
>> |
40 |
>> Tools that need to respect the /current/ profile should work |
41 |
>> without any change, and tools that need to respect the |
42 |
>> /available/ profiles (repoman) already do have a list of profiles |
43 |
>> to respect (profiles/profiles.desc). |
44 |
>> |
45 |
>> So the only missing thing would be the eselect profile module to |
46 |
>> manage entries of /etc/portage/make.profile/parent, maybe using |
47 |
>> /usr/portage/profiles/profiles.desc as the source for available |
48 |
>> flavours. |
49 |
>> |
50 |
>> my 2 cents /haubi/ |
51 |
> |
52 |
> That's the thing, make.profile technically *is* a directory -- a |
53 |
> symlink to one. The original design of make.profile was to specify |
54 |
> generic, base settings for a given profile and keep that in the |
55 |
> tree. Things like default CHOST, default ARCH, default <VARIABLE>, |
56 |
> etc. make.conf then overrides in-tree settings with settings |
57 |
> specific to your system. So making /etc/make.profile an actual |
58 |
> directory disconnects it from the tree, which I don't think will |
59 |
> work very well for Portage, since it won't know what your |
60 |
> currently-chosen profile is. |
61 |
> |
62 |
|
63 |
I did a test where I dropped my make.profile symlink, made a directory |
64 |
of the same name, and populated a 'parent' file in that directory with |
65 |
paths to various /usr/portage/profiles/ bits which made up my previous |
66 |
main profile. Everything continued to work as expected. |
67 |
|
68 |
I expect for portage proper, we could accomodate mixins or whatever |
69 |
new structure method we want simply by adjusting 'eselect profile' to |
70 |
list the various possible combinations and adjust an |
71 |
/etc/make.profile/parent file accordingly. |
72 |
|
73 |
(We probably also need to ensure portage warns or errors appropriately |
74 |
when one of these inherit lines in the parent file no longer points to |
75 |
a directory, the same as it does now with the symlink points to |
76 |
nothing; I didn't test but I expect that error would not be pretty or |
77 |
easily understood right now) |
78 |
|
79 |
|
80 |
|
81 |
|
82 |
-----BEGIN PGP SIGNATURE----- |
83 |
Version: GnuPG v2.0.22 (GNU/Linux) |
84 |
|
85 |
iF4EAREIAAYFAlO1f4IACgkQ2ugaI38ACPB1wgEApznnssegz2ImYIq6fAeR2oGa |
86 |
RX0TNT6bThDcypkn0skA/j/w33cWekomOQanCKIspuOWxXgOAeMxMWlnhsORZfj7 |
87 |
=Qwj0 |
88 |
-----END PGP SIGNATURE----- |