| 1 |
Zac Medico wrote: |
| 2 |
> Alec Warner wrote: |
| 3 |
> |
| 4 |
>> |
| 5 |
>> I have emerge rewritten ( somewhere ) for HEAD once all of Brian's |
| 6 |
>> config/domain/crazy stuff goes in, unless someone wants to unlease |
| 7 |
>> modular emerge now, in which case I can pull the code out of the cobwebs |
| 8 |
>> of my ${HOME} and work on it again. |
| 9 |
>> |
| 10 |
>> Basically the code allowed you to have a folder for modules that emerge |
| 11 |
>> would detect at run-time, and load the proper ones depending on user |
| 12 |
>> specification. The bonus to this was that some tools would be merged |
| 13 |
>> into emerge instead of being seperate, which many users got upset about. |
| 14 |
>> "emerge --rebuild" = revdep-rebuild -X for example. The main problem |
| 15 |
>> with this is basically the same as above; emerge serves about 12 |
| 16 |
>> different functions with crappy code everywhere, I managed to replicate |
| 17 |
>> about half the functionality by just copying and pasting important code |
| 18 |
>> everywhere, but most of it still needs to be completely rewritten ( |
| 19 |
>> *stabs depgraph* ). I was going to wait for the new API to be done ( no |
| 20 |
>> use rewriting emerge twice, IMHO ), but if you want it done now it |
| 21 |
>> wouldn't be a big deal. |
| 22 |
> |
| 23 |
> |
| 24 |
> Hmm, interesting. I can see how building other tools into the emerge |
| 25 |
> interface would be useful if it allows more code to be shared somehow |
| 26 |
> (and less duplication). Are there other reasons for combining other |
| 27 |
> tools into the same interface? |
| 28 |
> |
| 29 |
> My main concern about "rewritten" code is that, depending on the nature |
| 30 |
> of the code being rewritten, it may be likely to introduce unwanted |
| 31 |
> changes or regressions. Of course, thats why I put so much emphasis on |
| 32 |
> careful refactoring/reorganizing of existing code that is known to work |
| 33 |
> in the desired way. |
| 34 |
> |
| 35 |
> I don't see a reason to keep messy code around for long periods of time |
| 36 |
> when it can be so quickly reorganized. Why wait? Messy code only makes |
| 37 |
> more difficult the job of maintaining and improving the code. |
| 38 |
> |
| 39 |
> Zac |
| 40 |
|
| 41 |
It was my understanding that large patches to portage were not to |
| 42 |
receive great consideration due to just that, regressions and bugs. Why |
| 43 |
break something that is proven? I will agree that emerge is a huge |
| 44 |
piece, I've torn it apart more than once. However it currently does the |
| 45 |
job, so I don't see a point in rewriting it unless there is : a) an |
| 46 |
immediate benefit for users, and b) some sort of way to gaurantee a |
| 47 |
problem free update. |
| 48 |
|
| 49 |
I don't see a), they get prettier code to look at, but I wouldn't want |
| 50 |
people writing code against emerge. |
| 51 |
b) is hard to do, even if it's just function and variable re-organizing, |
| 52 |
it's 2000 lines of code that has a lot of interaction and there are |
| 53 |
going to be bugs. |
| 54 |
|
| 55 |
I just don't see the worth of it. Why rewrite the front-end when the |
| 56 |
backend isn't done? |
| 57 |
|
| 58 |
Not to mention you can upgrade the code here, and then upgrade it again |
| 59 |
to the new portage API in 2.1, since I would guess many calls are being |
| 60 |
refactored and rewritten to be object oriented. |
| 61 |
|
| 62 |
In the end nothing I say really matters, if you want to do the |
| 63 |
refactoring I certainly can't stop you, I just don't think it's worth it |
| 64 |
to rewrite at this time ;) |
| 65 |
-- |
| 66 |
gentoo-portage-dev@g.o mailing list |
Archives