| 1 |
On 01/02/12 12:06, Michael Mol wrote: |
| 2 |
> |
| 3 |
> That's the purpose of the "emerge -p" step. Presumably, you would see |
| 4 |
> that there's a package in the list that you're not comfortable with |
| 5 |
> removing, you'd decide you didn't want it removed, and you'd add it |
| 6 |
> back to your world set. |
| 7 |
|
| 8 |
Yeah, I'm not sure I can remove any of them. The only way I see to |
| 9 |
determine what's necessary at this point is to remove it and see if |
| 10 |
stuff breaks. |
| 11 |
|
| 12 |
|
| 13 |
> If you're not comfortable removing *any* package that's in your world |
| 14 |
> set, then, no, there's no way to tell the difference. From this point |
| 15 |
> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the |
| 16 |
> safest practice for your environment. And start keeping a list of |
| 17 |
> packages installed to meet customers' requests. Portage apparently |
| 18 |
> supports your desired workflow, but it needs to be set up for it. |
| 19 |
> |
| 20 |
> As to recovering from your current scenario...there might be some way |
| 21 |
> to watch your apache processes to identify which files get used over a |
| 22 |
> three-month span, from that list derive a list of which packages were |
| 23 |
> used, and from *that* list, derive a list of which packages weren't |
| 24 |
> used. (Or make an ebuild explicitly identifying the utilized |
| 25 |
> dependencies, and let depclean handle the rest) |
| 26 |
|
| 27 |
That's probably more work than copying everything to another box, |
| 28 |
emptying the world file, and adding things back until stuff works. |
| 29 |
|
| 30 |
Either way the current situation is "you're kinda screwed" which is why |
| 31 |
I proposed avoiding it in the future (for others, too) by fixing --update. |
Archives