From batsman.geo@yahoo.com Sat Sep 25 10:37:14 2004 Date: Sat, 25 Sep 2004 10:37:14 +0200 From: Mauricio =?iso-8859-1?Q?Fern=E1ndez?= To: leon breedt Subject: Re: rpa2rpm Message-ID: <20040925083714.GA12551@student.ei.uni-stuttgart.de> References: <270bd0c404092220212963ef7d@mail.gmail.com> <20040923095057.GB5676@student.ei.uni-stuttgart.de> <270bd0c4040923032732ebd931@mail.gmail.com> <20040923110530.GA14916@student.ei.uni-stuttgart.de> <270bd0c404092305076fd7fc18@mail.gmail.com> <20040923125213.GA21070@student.ei.uni-stuttgart.de> <270bd0c4040923183145684a4d@mail.gmail.com> <20040924081800.GA12492@student.ei.uni-stuttgart.de> <270bd0c4040924231126418807@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <270bd0c4040924231126418807@mail.gmail.com> User-Agent: Mutt/1.3.28i Status: RO Content-Length: 4091 Lines: 91 On Sat, Sep 25, 2004 at 06:11:45PM +1200, leon breedt wrote: > hi, > > thanks for all the clarifications so far, i apologize for all the > questions...its taken me a while to get my head around some of the > code. Yes, I fear rpa-base's code is a bit hard to follow... rpa/install.rb in particular is quite dense. > i've gotten to the point where i'm able to run only the tasks i > require for the build phase, and i have an interceptor that gets > called into at various stages so it knows which metadata is associated > with which files (roughly speaking). > its a bit of a hack tho, as i've had to override some HelperBase > methods. especially the way i determine RDoc files is a bit dodgy :) I hadn't thought of intercepting the file operations themselves. My original intention was getting the list of helpers (plus their arguments) and mapping them into "helpers from the destination platform/system", so to speak. That would involve effectively redefining the behavior of rpa-base's helpers, probably by subclassing and overriding methods like self.default_base_destdir, etc... We could put them under RPA::SystemAdapters:: (e.g. RPA::SystemAdapters::PLD, RPA::SystemAdapters::Debian, etc, but we'd also have to find a way to reflect policy changes in the dest. system). Some platforms might have some "helpers" of their own (for instance, a dh_ruby_* might be on the way), but in general we'd have to implement them (and doing so might be easier in fact). rpa-base's "native" helpers should be as fine-grained as required, so that the class of the helper carries enough semantic information to do "intelligent" mappings. I'm unsure about intercepting it at the file level --- my gut feeling is that it's too low-level, but since you can also get the corresponding Helper via the hooks you've added, it should be strictly more powerful than mapping at the Helper level; however I'm not sure per-file information is useful. > i think a cleaner implementation would be the ability to register an > event listener somewhere, and then have the helpers emit events (such > as a FileOperationEvent, and RunEvent), the event objects containing > all the data required for a listener to be able to do something > meaningful. This sounds good :) > i can do the implementation of such an event listener/emitter, just > wondering if you have any strong opinions or ideas for alternative > approaches. As I said above, I believe most of the RPA policy => destination policy mapping should be done at the Helper level. But there's surely no harm in implementing the observer model at all levels, besides added complexity :) > i've attached what i have so far (this is just a snippet to prove that > a managed build is possible currently, the real code will be much > cleaner :) It's not bad at all -- the unclean bits are my fault, for I didn't make the Helper system easy enough to extend. I'm thinking of creating a new rpa-base0.3 (or maybe even rpapkg0.3 to make the rename effective) branch... Unfortunately, I am moving this week (which implies relocating my devel. box, etc) and will be quite busy, so I won't be able to do much in the next few days. Actually, I might have no internet connection for a few days. Do you think that direct access to the svn repos would be helpful to you? I can ask David Black to give you ci access if you want (he runs our SVN repos currently, we'll eventually move to our new machine). cheers, PS: regarding batsman: any particlular reason installing RPA puts the rpa/*.rb files in both /usr/lib/ruby/rpa0.0/1.8 and /usr/local/lib/site_ruby/1.8 ? => it's a cheap hack to have both require 'foo' and require 'rpa'; RPA.version="0.0"; require 'foo' to work; the later uses the files from lib/ruby/rpa0.0/1.8. Of course, this should be managed with symlinks (or managed copies on win32), and in fact the new concepts I want to introduce in 0.3 ("API/package clusters", cherry-picking, etc) will require rpa-base to have much of GNU stow's functionality. -- Running Debian GNU/Linux Sid (unstable) batsman dot geo at yahoo dot com