[Ifeffit] Re: debian packages

[Carlo U. Segre]

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 at iit.edu    http://www.iit.edu/~segre