1 |
On Mon, Jan 2, 2012 at 4:48 PM, Michael Orlitzky <michael@××××××××.com> wrote: |
2 |
> On 01/02/2012 04:34 PM, Michael Mol wrote: |
3 |
>> |
4 |
>> On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky<michael@××××××××.com> |
5 |
>> wrote: |
6 |
>>> |
7 |
>>> On 01/02/2012 04:11 PM, Alan McKinnon wrote: |
8 |
>>>> |
9 |
>>>> |
10 |
>>>> cocktail |
11 |
>>>> Neil's suggestion of sets sounds like what you want here. Unfortunately |
12 |
>>>> it only works smoothly on first emerge (later on you have to dig |
13 |
>>>> through dep graphs to find the full dep list): |
14 |
>>>> |
15 |
>>>> First run emerge -p to find all the packages that will be pulled in, |
16 |
>>>> and add the whole lot to a set with a clear name that indicates it's |
17 |
>>>> function. Then emerge that set. As you discover further deps you can |
18 |
>>>> manually add them to the set |
19 |
>>>> |
20 |
>>>> It's quite a lot of extra work and you have to remember to do it, but |
21 |
>>>> it has the benefit of being somewhat self-documenting, at least in |
22 |
>>>> terms of having a record of what set pulled a package in initially. |
23 |
>>>> |
24 |
>>> |
25 |
>>> Requires time travel, not a solution! |
26 |
>> |
27 |
>> |
28 |
>> Seriously. Do you want a solution, or do you just want to rant about a |
29 |
>> change to the behavior of --update? |
30 |
>> |
31 |
> |
32 |
> All I originally wanted to know was if anyone had a real reason to prefer |
33 |
> the current behavior over the old. |
34 |
|
35 |
Ah. I must have gotten confused at "So which ones can I remove? |
36 |
Solutions involving time travel and/or losing customers will be |
37 |
disqualified." |
38 |
|
39 |
> |
40 |
> I've shown that there's a problem with the current behavior; if there are no |
41 |
> real problems with the old behavior, then it's worth raising the issue. |
42 |
|
43 |
Ah. Then based on the conversation thus far, it sounds like you'd have |
44 |
to ask the developer who made the change. |
45 |
|
46 |
> |
47 |
> I know how to avoid the problem in the future, but there are plenty of other |
48 |
> Gentoo users who don't, and who also won't be able to fix today's mistakes a |
49 |
> year from now. |
50 |
|
51 |
-- |
52 |
:wq |