Bruce, Matt: I have made some significant progress today. I now have installable Debian packages for ifeffit, atoms and horae. They seem to function correctly as a unit but I have not tested them thoroughly as yet. I do have a couple of questions for Bruce. These relate to perl modules included in horae and duplicate files between atoms and horae. If you can give me some guidance on what to do, the horae package will install more smoothly. 1. horae overwrites two files which are already in atoms ./bin/tkpod ./share/man/man3/Chemistry::Elements.3pm.gz Are these different files in the two programs? Is there are good reason why they need to be in horae since horae seems to depend on atoms being installed (at least that is how I would like to structure Debian dependencies)? If they can safely be removed from horae, what is the best way to modify the source tree for this purpose? 2. horae has the Tie-Watch perl module included which is in the standard Debian perl-tk package. Is your version significantly different that the stock version? if not, what will be the best way to remove it from teh distribution since horae should be dependent on perl-tk being installed anyway? 3. horae seems to rewrite another module which is in perl-tk ./lib/perl5/Tk/FBox.pm Again, is this different than the stock version and how can it be removed from the source distribution for Debian packaging? After resolving these issues, I will move on to producing a gifeffit installtion and getting the documentation properly installed as well. In the meantime, I can force the installation and at least test the executables. Thanks in advance... Carlo On Wed, 5 Mar 2003, Bruce Ravel wrote:
Hi Carlo,
At the risk of being the obnoxious guy who's always chock-full of ideas for work that other people can do ....
I'd like to recommend that, once you are happy with your .debs, you do a bit more work. Ifeffit and my codes are, as you well know, ongoing and frequently updated projects. The problem with any given .deb (or .rpm or whatever) is that it is prone to fall out of date rather quickly. I would strongly encourage you to automate *fully* the process of building your .debs.
Both Matt and I put our source packages in predictable places and under predictable names. For example, the ifeffit tarball is always in http://cars9.uchicago.edu/ifeffit/src/ and is always called "ifeffit-X.XXXX.tar.gz", where X.XXXX is the version number. I do the similar thing with the horae tarballs.
You could have a cron job that checks the web sites every night to see if the tarballs have been updated (easy to do since the tarballs follow well-defined naming conventions). If they have been, then have the cron job 1. download the latest 2. build the .deb from the tarball 3. upload the new .deb to a web site and perhaps 4. send an short, auto-generated note to the mailing list saying that the new .deb is in place
I think you would appreciate having done the work of automation during one of those weeks where someone finds a bug in my code a few hours after I make a new release (it's happened more than once ;-), and I make a new release the next day.
I would, unsurprisingly, make the same suggstion of anyone else out there in ifeffit-land who wants to make, say, Red Hat .rpms or Fink .debs or whatever.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre