From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E3hOo-00014C-Iz for garchives@archives.gentoo.org; Fri, 12 Aug 2005 21:49:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7CLmXm4031418; Fri, 12 Aug 2005 21:48:33 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7CLmWB6002842 for ; Fri, 12 Aug 2005 21:48:33 GMT Received: from [35.9.44.33] (caffeine [35.9.44.33]) (authenticated bits=0) by egr.msu.edu (8.13.4/8.13.4) with ESMTP id j7CLmX7r029202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2005 17:48:33 -0400 (EDT) Message-ID: <42FD193D.8010200@egr.msu.edu> Date: Fri, 12 Aug 2005 17:48:45 -0400 From: warnera6 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073)) References: <42FADD3A.7020103@gmail.com> <200508112306.20986.jstubbs@gentoo.org> <42FC3163.2080709@gmail.com> <42FC97C9.7050301@egr.msu.edu> <42FD0D42.3020500@gmail.com> In-Reply-To: <42FD0D42.3020500@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: e1564584-ba77-4dd8-8c0d-121ee35dc9a2 X-Archives-Hash: 20eaa6b055a4657a4cc390bfb4e16270 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