1 |
On 11/14/2014 06:14 AM, Andrew Savchenko wrote: |
2 |
> Hi, |
3 |
> |
4 |
> On Fri, 14 Nov 2014 07:20:50 -0500 Anthony G. Basile wrote: |
5 |
>> On 11/13/14 23:15, Zac Medico wrote: |
6 |
>>> On 11/13/2014 08:01 PM, Rich Freeman wrote: |
7 |
>>>> On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka <kensington@g.o> wrote: |
8 |
>>>>> On 14/11/14 11:06, Rich Freeman wrote: |
9 |
>>>>>> Well, the idea would be to maintain the virtual INSTEAD of @system, or |
10 |
>>>>>> have @system just pull in the virtual and make some arch-specific |
11 |
>>>>>> additions. |
12 |
>>>>> Will that work? Some profiles remove packages from the base @system and |
13 |
>>>>> replace it with their own implementations (eg. BSD). |
14 |
>>>> Maybe. The thing is that a package either depends on something or it |
15 |
>>>> doesn't. If it really does depend on something, then the fact that it |
16 |
>>>> isn't available on BSD/etc isn't going to magically make the package |
17 |
>>>> work. We just loosely define system dependencies in a way that makes |
18 |
>>>> them work 98% of the time, basically accepting that things are going |
19 |
>>>> to break and we get away with it because few of our users actually run |
20 |
>>>> on BSD/etc. |
21 |
>>>> |
22 |
>>>> If it is just a matter of preference then a profile could install an |
23 |
>>>> alternative package that is in a virtual. However, this won't work if |
24 |
>>>> everybody still uses some convenience virtual that pulls in bash/etc |
25 |
>>>> and the BSD folks don't want to install bash unnecessarily. |
26 |
>>> Maybe I'm missing something, but if you are using virtuals, then you can |
27 |
>>> make the deps conditional on profile forced/masked flags like |
28 |
>>> userland_BSD and userland_GNU if necessary. These behave like normal USE |
29 |
>>> flags, aside from the fact the they are forced or masked by profiles. |
30 |
>> |
31 |
>> Sorry Zac, I posted my reply before I read this. This is essentially |
32 |
>> the point I was making. However, I think this will be cumbersome. With |
33 |
>> the current way we do things, its easy to delete packages from @system |
34 |
>> by just doing '-*sys-apps/man-pages' (for example) in a profile's |
35 |
>> packages file. It is not so easy to delete from a DEPEND string, so I |
36 |
>> foresee some tricky if logic here. |
37 |
> |
38 |
> There is another drawback of using virtuals instead of @system set. |
39 |
> For old systems (in practical terms they are systems not updated |
40 |
> @world for more than several month) it is wise to update kernel, |
41 |
> @system and only afterwards whole @world. |
42 |
> |
43 |
> Virtuals will not catch updates in underlying packages if --deep is |
44 |
> not used and it can't be used, because some packages from @system |
45 |
> may indirectly depend on packages from @world (e.g. cairo, qt or |
46 |
> xorg) which will trigger half of the @world update with -D @system |
47 |
> which makes it impossible and impractical to use -D @system before |
48 |
> full @world update on old setups. |
49 |
> |
50 |
> We already have this problem with virtua/libc: it is not updated at |
51 |
> all, so when I run emerge -uav @system for the purposes described |
52 |
> above I have to manually add sys-devel/glibc to the list. |
53 |
|
54 |
There was a time long ago when portage actually behaved the way you want |
55 |
here. I implemented the behavior myself, but then I changed it to the |
56 |
way it is now because others complained that "virtuals should behave |
57 |
just like normal packages." We could certainly add an emerge option |
58 |
which would trigger the behavior that you want. |
59 |
-- |
60 |
Thanks, |
61 |
Zac |