Re: [gentoo-user] emerge --update behavior

[Michael Mol]

On Mon, Jan 2, 2012 at 11:33 AM, Michael Orlitzky <michael@××××××××.com> wrote:
> On 01/02/2012 11:16 AM, Michael Mol wrote:
>>>
>>>
>>> Fine for your home PC, doesn't cut it on servers. I have the following in
>>> one of my world files:
>>>
>>>  dev-php/PEAR-Mail
>>>  dev-php/PEAR-Mail_Mime
>>>  dev-php/PEAR-PEAR
>>>  dev-php/PEAR-Structures_Graph
>>>
>>> which of those do I want? At least one of them was installed to support a
>>> customer's custom PHP application. Maybe all of them were and they all
>>> belong in world. No one knows, this server is older than the current
>>> --update behavior.
>>>
>>> So which ones can I remove?
>>>
>>> Solutions involving time travel and/or losing customers will be
>>> disqualified.
>>
>>
>> Make a backup copy of your world file.
>>
>> 1a. Remove those four lines.
>> 2a. emerge -p --depclean
>> 3a. Did any of those show up in the to-be-removed set? Add them back.
>>
>> Alternately:
>> 1b. emerge -pev --tree --with-bdeps=y @world
>> 2b Find those packages in the output. The tree form of the display
>> will help you see if anything is depending on them.
>> 3b. If anything is depending on them, you should be able to safely
>> remove them from your world file. I'd follow up with the 1a, 2a, 3a
>> solution to be sure.
>>
>
> Sorry, but these won't work.
>
> Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail,
> but I have a customer who needs dev-php/PEAR-Mail for a contact form.
>
> Following your process, I would remove dev-php/PEAR-Mail from my world file.
> If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and
> break the guy's site.

That's the purpose of the "emerge -p" step. Presumably, you would see
that there's a package in the list that you're not comfortable with
removing, you'd decide you didn't want it removed, and you'd add it
back to your world set.

If you're not comfortable removing *any* package that's in your world
set, then, no, there's no way to tell the difference. From this point
forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the
safest practice for your environment. And start keeping a list of
packages installed to meet customers' requests. Portage apparently
supports your desired workflow, but it needs to be set up for it.

As to recovering from your current scenario...there might be some way
to watch your apache processes to identify which files get used over a
three-month span, from that list derive a list of which packages were
used, and from *that* list, derive a list of which packages weren't
used. (Or make an ebuild explicitly identifying the utilized
dependencies, and let depclean handle the rest)

-- 
:wq