1 |
On Mon, Jan 2, 2012 at 9:39 AM, Michael Orlitzky <michael@××××××××.com> wrote: |
2 |
> On 01/02/12 12:06, Michael Mol wrote: |
3 |
>> |
4 |
>> That's the purpose of the "emerge -p" step. Presumably, you would see |
5 |
>> that there's a package in the list that you're not comfortable with |
6 |
>> removing, you'd decide you didn't want it removed, and you'd add it |
7 |
>> back to your world set. |
8 |
> |
9 |
> Yeah, I'm not sure I can remove any of them. The only way I see to |
10 |
> determine what's necessary at this point is to remove it and see if |
11 |
> stuff breaks. |
12 |
> |
13 |
|
14 |
Again, 'equery depends' will tell you if any package locatable through |
15 |
the @world hierarchy needs the package. No need to uninstall anything |
16 |
to do that level of investigation. revdep-rebuild -I is also useful, |
17 |
although more historically than now. |
18 |
|
19 |
> |
20 |
>> If you're not comfortable removing *any* package that's in your world |
21 |
>> set, then, no, there's no way to tell the difference. From this point |
22 |
>> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the |
23 |
>> safest practice for your environment. And start keeping a list of |
24 |
>> packages installed to meet customers' requests. Portage apparently |
25 |
>> supports your desired workflow, but it needs to be set up for it. |
26 |
>> |
27 |
>> As to recovering from your current scenario...there might be some way |
28 |
>> to watch your apache processes to identify which files get used over a |
29 |
>> three-month span, from that list derive a list of which packages were |
30 |
>> used, and from *that* list, derive a list of which packages weren't |
31 |
>> used. (Or make an ebuild explicitly identifying the utilized |
32 |
>> dependencies, and let depclean handle the rest) |
33 |
> |
34 |
> That's probably more work than copying everything to another box, |
35 |
> emptying the world file, and adding things back until stuff works. |
36 |
> |
37 |
> Either way the current situation is "you're kinda screwed" which is why |
38 |
> I proposed avoiding it in the future (for others, too) by fixing --update. |
39 |
> |
40 |
|
41 |
Really, the proposal to 'fix --update' doesn't address really knowing |
42 |
what your system is running and why. Get to the root of that and the |
43 |
--update thing becomes the non-issue that many of us think it is. |
44 |
|
45 |
- Mark |