| 1 |
On Mon, 02 Mar 2015 09:26:34 -0500 |
| 2 |
Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
| 3 |
|
| 4 |
> > In this specific case, all except two files come from emul-linux 32 |
| 5 |
> > bit and they are all safe to delete (even the two except ones). But |
| 6 |
> > do note I know this becuase I've been here before and figured it |
| 7 |
> > out, not becuase of some magic portage flag. |
| 8 |
> |
| 9 |
> Thanks Alan... |
| 10 |
> |
| 11 |
> So... how would one know, for sure, if and when these are safe to |
| 12 |
> delete? Would that be only if I know for sure that I did not manually |
| 13 |
> install these myself or put them there (which I haven't and most |
| 14 |
> likely wouldn't, but would remember if I did)? |
| 15 |
|
| 16 |
|
| 17 |
I don't have a recipe for this or even a rule of thumb. I usually know |
| 18 |
what the files are for (or can Google it) and decide on each case |
| 19 |
individually. |
| 20 |
|
| 21 |
For perl-cleaner output, the perl version of the old install is in the |
| 22 |
pathname, so I check if the corresponding file for the new perl version |
| 23 |
is already installed, that tells me the old one is safe to delete. On a |
| 24 |
64bit system, I know the 32bit files come from emul-linux, so I can |
| 25 |
delete those too on the same basis. |
| 26 |
|
| 27 |
For everything else from perl-cleaner, I have to figure out why I |
| 28 |
changed the file myself and make sure the same change is present in the |
| 29 |
new version. |
| 30 |
|
| 31 |
It gets more complicated if you use cpan (stuff can get changed behind |
| 32 |
the scenes). So the best approach is always to understand what the |
| 33 |
various tools do and deal with it on that basis. |
| 34 |
|
| 35 |
Alan |
Archives