1 |
> On Jul 11, 2018, at 4:42 PM, William Hubbs <williamh@g.o> wrote: |
2 |
> |
3 |
>> On Wed, Jul 11, 2018 at 04:25:20PM -0400, Richard Yao wrote: |
4 |
>>> On 07/11/2018 03:29 AM, Jory A. Pratt wrote: |
5 |
>>>> On 07/10/18 16:35, M. J. Everitt wrote: |
6 |
>>>>> On 10/07/18 21:09, William Hubbs wrote: |
7 |
>>>>>> On Mon, Jul 09, 2018 at 03:54:35PM -0700, Zac Medico wrote: |
8 |
>>>>>>> On 07/09/2018 03:27 PM, M. J. Everitt wrote: |
9 |
>>>>>>>> On 09/07/18 23:12, Zac Medico wrote: |
10 |
>>>>>>>>> On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: |
11 |
>>>>>>>>> I'd mostly argue any such change should only affect new systems |
12 |
>>>>>>>>> |
13 |
>>>>>>>> Yes, changing defaults for existing systems would be annoying. |
14 |
>>>>>>>> |
15 |
>>>>>>>> My recommendation is to have catalyst set the new defaults in the stage |
16 |
>>>>>>>> tarballs. |
17 |
>>>>>>>> |
18 |
>>>>>>>> When sys-apps/portage changes its internal defaults, I'd like for the |
19 |
>>>>>>>> upgrade process to call a tool that generates configuration files when |
20 |
>>>>>>>> necessary to ensure that the existing paths remain constant. |
21 |
>>>>>>> I think it should be possible for RelEng to make a start on catalyst |
22 |
>>>>>>> updates - is there anything that would inhibit going ahead with this, |
23 |
>>>>>>> potentially? |
24 |
>>>>>> No, nothing. Whatever catalyst puts it the default config will become |
25 |
>>>>>> our new default. |
26 |
>>>>> I would still like to see notice about what the new defaults are and how |
27 |
>>>>> to migrate current systems to them. |
28 |
>>>>> |
29 |
>>>>> |
30 |
>>>>> Thanks, |
31 |
>>>>> |
32 |
>>>>> William |
33 |
>>>>> |
34 |
>>>>>> -- |
35 |
>>>>>> Thanks, |
36 |
>>>>>> Zac |
37 |
>>>>>> |
38 |
>>>>> |
39 |
>>>>> |
40 |
>>>> I'd like to propose that further to the discussion here on the -dev |
41 |
>>>> mailing list, the Council discuss and make a firm proposal on the new |
42 |
>>>> default paths, and then RelEng can make the appropriate updates to the |
43 |
>>>> catalyst builds. A news item can be compiled, with an appropriate wiki |
44 |
>>>> article perhaps on migration strategy (I may volunteer to format such a |
45 |
>>>> page with some appropriate guidance). |
46 |
>>>> Regards, |
47 |
>>>> Michael / veremitz. |
48 |
>>>> |
49 |
>>> This is a mess, many systems are setup with portage already on a |
50 |
>>> seperate partition for reasons. What advantage does it provide to move |
51 |
>>> the tree now after all these years? I have seen nothing more then lets |
52 |
>>> do this cause I like the ideal lately and it is getting old, there is no |
53 |
>>> benefit that would justify moving the tree or many other changes that |
54 |
>>> are being made in Gentoo lately. |
55 |
>> |
56 |
>> People who want to move it could just set PORTDIR in make.conf. I don't |
57 |
>> see any reason to move it either. |
58 |
> |
59 |
> Actually, I believe that PORTDIR is becoming a thing of the past. |
60 |
I used to use it 5 years ago. If it does not work due to regressions, we should fix that. |
61 |
> |
62 |
> Also, the default definitely should not be on /usr per fhs. This would |
63 |
> allow /usr to be mounted read only. |
64 |
> This doesn't affect things like the example above where /usr/portage is |
65 |
> a mount point. |
66 |
> |
67 |
>>> |
68 |
>>> |
69 |
>>> |
70 |
>> |
71 |
>> |
72 |
> |
73 |
> |
74 |
> |