| 1 |
On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky <michael@××××××××.com> wrote: |
| 2 |
> On 01/02/2012 04:11 PM, Alan McKinnon wrote: |
| 3 |
>> |
| 4 |
>> cocktail |
| 5 |
>> Neil's suggestion of sets sounds like what you want here. Unfortunately |
| 6 |
>> it only works smoothly on first emerge (later on you have to dig |
| 7 |
>> through dep graphs to find the full dep list): |
| 8 |
>> |
| 9 |
>> First run emerge -p to find all the packages that will be pulled in, |
| 10 |
>> and add the whole lot to a set with a clear name that indicates it's |
| 11 |
>> function. Then emerge that set. As you discover further deps you can |
| 12 |
>> manually add them to the set |
| 13 |
>> |
| 14 |
>> It's quite a lot of extra work and you have to remember to do it, but |
| 15 |
>> it has the benefit of being somewhat self-documenting, at least in |
| 16 |
>> terms of having a record of what set pulled a package in initially. |
| 17 |
>> |
| 18 |
> |
| 19 |
> Requires time travel, not a solution! |
| 20 |
|
| 21 |
Seriously. Do you want a solution, or do you just want to rant about a |
| 22 |
change to the behavior of --update? |
| 23 |
|
| 24 |
Without some existing log of the things your existing customers |
| 25 |
specifically need, and without some means to intuit what they need by |
| 26 |
the web apps they've uploaded to their accounts, there isn't going to |
| 27 |
be any solution that isn't going to involve either a risk of breakage |
| 28 |
to your existing clients' sites, preservation of your damaged world |
| 29 |
file as an "assume this is what I need" set, or a great deal of work |
| 30 |
coming up with the list of things you actually need. |
| 31 |
|
| 32 |
Without that request log, you're in a *recovery* scenario, and there |
| 33 |
is no quick fix. All solutions offered that aren't time travel (better |
| 34 |
termed, "change your practices so this doesn't happen again"), are |
| 35 |
going to require a lot of effort and legwork on your part, and will |
| 36 |
*all* carry risk. |
| 37 |
|
| 38 |
Here's another time travel solution, but this one doesn't require |
| 39 |
changing past actions: Go through your log files and look for |
| 40 |
'Updating world file", and look at what portage was doing at the time. |
| 41 |
Go through your emails with your customers and identify which packages |
| 42 |
they requested. Look at your own public-facing website and look at the |
| 43 |
list of packages you promise. |
| 44 |
|
| 45 |
If you either have all your emerge logs, or all your customer contact |
| 46 |
logs, it's doable. |
| 47 |
|
| 48 |
-- |
| 49 |
:wq |
Archives