| 1 |
On 09/09/2014 02:38 PM, Brian Dolbec wrote: |
| 2 |
> On Mon, 1 Sep 2014 22:05:45 -0700 |
| 3 |
> Brian Dolbec <dolsen@g.o> wrote: |
| 4 |
> |
| 5 |
>> This code had portage bin path hard coded. That path needed to be |
| 6 |
>> changed for a new portage ebuild and install system. |
| 7 |
>> After testing the origianl code and comparing it with some updated |
| 8 |
>> code supplied by Douglas Freed. It turned out both code chunks |
| 9 |
>> resulted in nothing being cleaned. |
| 10 |
>> |
| 11 |
>> Tested and confirmed by zero_chaos. |
| 12 |
> |
| 13 |
> I have gone over things more and tested the new find command. It does |
| 14 |
> work on my host system. However, the question remains... DOES this |
| 15 |
> particular cleaning operation NEED to be performed? |
| 16 |
> |
| 17 |
> With current the tree snapshot for my testing 20140829. It does not |
| 18 |
> find anything to clean. BUT, will that remain the same in the future |
| 19 |
> as pkgs are bumped? |
| 20 |
> |
| 21 |
> For safety, I'd be inclined to keep the find command (v1 of the |
| 22 |
> patch) and clean any it does find just in case. |
| 23 |
> |
| 24 |
|
| 25 |
If we truly need to remove these files, I don't think catalyst was ever |
| 26 |
the place to do this. We have USE=static and USE=static-libs for a |
| 27 |
reason. Randomly removing files from the filesystem was a hack then, |
| 28 |
and if we are cleaning this up let's just remove it. If I want to build |
| 29 |
things with USE=static or USE=static-libs then catalyst shouldn't be |
| 30 |
pointlessly crippling my builds. |
| 31 |
|
| 32 |
v2 means one less horrible hack in catalyst, and one at a time is the |
| 33 |
only way will remove all the horror. |
| 34 |
|
| 35 |
-Zero |
Archives