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 ;)
--
[email protected] mailing list
