Re: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073))

[warnera6 <warnera6@egr.msu.edu>]

Zac Medico wrote:
> Alec Warner wrote:
> 
>>
>>   I have emerge rewritten ( somewhere ) for HEAD once all of Brian's
>> config/domain/crazy stuff goes in, unless someone wants to unlease
>> modular emerge now, in which case I can pull the code out of the cobwebs
>> of my ${HOME} and work on it again.
>>
>> Basically the code allowed you to have a folder for modules that emerge
>> would detect at run-time, and load the proper ones depending on user
>> specification.  The bonus to this was that some tools would be merged
>> into emerge instead of being seperate, which many users got upset about.
>> "emerge --rebuild" = revdep-rebuild -X for example.  The main problem
>> with this is basically the same as above; emerge serves about 12
>> different functions with crappy code everywhere, I managed to replicate
>> about half the functionality by just copying and pasting important code
>> everywhere, but most of it still needs to be completely rewritten (
>> *stabs depgraph* ).  I was going to wait for the new API to be done ( no
>> use rewriting emerge twice, IMHO ), but if you want it done now it
>> wouldn't be a big deal.
> 
> 
> Hmm, interesting.  I can see how building other tools into the emerge 
> interface would be useful if it allows more code to be shared somehow 
> (and less duplication).  Are there other reasons for combining other 
> tools into the same interface?
> 
> My main concern about "rewritten" code is that, depending on the nature 
> of the code being rewritten, it may be likely to introduce unwanted 
> changes or regressions.  Of course, thats why I put so much emphasis on 
> careful refactoring/reorganizing of existing code that is known to work 
> in the desired way.
> 
> I don't see a reason to keep messy code around for long periods of time 
> when it can be so quickly reorganized.  Why wait?  Messy code only makes 
> more difficult the job of maintaining and improving the code.
> 
> Zac

It was my understanding that large patches to portage were not to 
receive great consideration due to just that, regressions and bugs.  Why 
break something that is proven?  I will agree that emerge is a huge 
piece, I've torn it apart more than once.  However it currently does the 
job, so I don't see a point in rewriting it unless there is : a) an 
immediate benefit for users, and b) some sort of way to gaurantee a 
problem free update.

I don't see a), they get prettier code to look at, but I wouldn't want 
people writing code against emerge.
b) is hard to do, even if it's just function and variable re-organizing, 
  it's 2000 lines of code that has a lot of interaction and there are 
going to be bugs.

I just don't see the worth of it.  Why rewrite the front-end when the 
backend isn't done?

Not to mention you can upgrade the code here, and then upgrade it again 
to the new portage API in 2.1, since I would guess many calls are being 
refactored and rewritten to be object oriented.

In the end nothing I say really matters, if you want to do the 
refactoring I certainly can't stop you, I just don't think it's worth it 
to rewrite at this time ;)
-- 
gentoo-portage-dev@gentoo.org mailing list