IRAF Deb -- first pass
Hi Paul, Zed, and Mike
[and I've CC'd debian-mentors, in case anyone else would like to offer some help or comments too]
I have successfully built the core IRAF package from source,
and I have created a Debian package for it. It does not
yet work as I would like it to, and I still get package errors on installation, though I think these are relatively trivial problems (looks like I must have doc-base configured
wrong, for example).
More detail is in the README I put in with the sources,
and which I've included below this message for those who
don't want to have to download the monster just to read the README. I've put all the source information and debian-generated files into one tarball which you can download from:
http://www.anansispaceworks.net/Local/iraf-2.12-deb_sources.tgz
Fair warning: this is a 38 megabyte file.
I plan to spend some time reviewing Zed's iraf-2.11.3 package to see what decisions he made about installation.
My package installs into /opt/iraf/iraf which seems to make
sense from the FHS standard, as I read it (because this seems to be the most appropriate place for "package-organized" rather than "distributed-components" packages to be placed). The structure is the cannonical structure that most IRAF network installations use (and indeed is enforced by the newer "install" that comes with IRAF 2.12):
/opt/iraf
iraf -- here's where most of the package installs
irafbin
bin.linux -- the binaries
extern -- this is empty, but external "iraf-" packages
will go here
There will also need to be an iraf-x11 that installs into /opt/iraf/x11iraf
All of which means there will eventually need to be an
"IRAF Policy" for Debian to make these things work together,
just as there is for Python, Perl, Java, etc. I can write something like this up, of course, but I think it needs to
be discussed quite a bit. I'm not even a Debian maintainer
at this point, and I am still quite ignorant of the finer points of Debian's overall policy (yes, I've read through the "Debian Policy" document once, that's not what I mean, though), as well as lacking experience with the tools to
even know what's feasible and what's not.
Anyway, please let me know what you think. Any suggestions
will be much appreciated.
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Hi!
***DISCLAIMER***
This is an EXTREMELY raw first hack at getting IRAF 2.12 into a Debian
package. It is NOT fully functional, so be warned. I made this bundle
so that I could share the result of my work so far with Zed Pobre,
Paul Scott, and Mike Fitzpatrick who have worked with me on this. So
I'm just saying it's very, very ALPHA.
WHAT'S INCLUDED
The included .deb file does install, but it currently complains about
errors involved in installing the HTML help files into the doc-base
system. I think that's a relatively trivial problem, but I'm not sure
why it's happening.
The more important issue is the absence of any preinst or postinst
scripts. IRAF *does* require some postinst installation, and there
are two installation csh scripts: $iraf/unix/hlib/install and
$iraf/unix/hlib/install.old which are for this purpose. But they
are not compliant with Debian policy, and are a bit awkward to use
at present.
What SHOULD happen is that the install/install.old scripts get
translated to bash or perl (maybe python?), have all of the user
interaction removed into a separate script, using debconf calls to
query the user, and the rest of the script made to run completely
in batch. Then the user-interaction part becomes "preinst" and
the batch part becomes "postinst". That would be the ideal
Debian way to do it. But it does mean quite a bit of work.
An acceptable halfway step might be to run the existing install
interactively from postinst. But this is complicated by the fact
that, as currently written, it will fail if the "noao" package is
not installed along with IRAF. Using install.old may be an alternative,
but it seems to need some hacking to work properly for us, too.
Furthermore, because of a source-dependency on the TABLES package,
which comes from a *different* upstream source (STScI) than IRAF
does (NOAO), I do not included the sources from nor attempt to build
or install the "noao" layered package for IRAF, even though this is
against the long-standing convention of bundling it with the base
IRAF.
I'm still waffling over how to handle that. I think the best thing
is for tables, noao, and stsdas to all be separate "iraf-" packages
in Debian. But how to handle the source trees is still complicated,
since the "IRAF Way" is to load them into a live IRAF instance and
build them in place, while the "Debian Way" would be for them to
have their own separate source trees. I'm still very new at building
packages for Debian, so this is something I hope to learn about in
the process.
Also, we have a bit of a "cultural conflict" in that IRAF, following
long-standind tradition in the astronomical community makes heavy
use of csh/tcsh for scripting. But of course, in the free software/
Debian community, csh is a bit of a pariah for technical reasons
limiting its effectiveness as a shell-scripting language. And, well,
even though I acknowledge that these problems are real, I know csh,
but not bash, so guess which I've used the most?
I've tried to move some things into the debian/rules file (which
uses Makefile syntax). You should generally assume I'm using tcsh
as my shell, when interpreting commands in my instructions, too.
HOW TO BUILD THE DEB PACKAGE
Using this archive, you *should* (I hope) be able to rebuild my
deb file by doing the following 5 steps:
1) Unpack this archive, and get into the top level of it (I think
it's called "iraf-2.12-deb_sources").
2) source ./UNPACK_IRAF.csh
this will set some environment variables and unpack the tarball
I've made from the upstream sources. REPACK_IRAF.csh won't run
on your system, but documents how I made the tarball on mine.
3) cd iraf-2.12
dh_make -e <your-email-address> --single
This does some housekeeping and creates a debian subdirectory
(but we're about to clobber that directory, so don't worry about
it).
4) source ./APPLY_CHANGES.csh
This does a number of things such as copying parts of the
iraf.debian, iraf.overlay, and applying diffs to the code to
reproduce what I did to it.
5) dpkg-buildpackage -rfakeroot -sgpg
This actually builds IRAF, installs it into a subdirectory in
debian, and then builds the .deb and associated files. You will
be asked to sign the result -- I think you can skip this if
you want (see "man dpkg-buildpackage") and if you just press
enter a few times it will give up and do it unsigned anyway.
The build is accomplished by running BUILD_TARGET.csh at
present, so you may want to look at that for documentation
purposes. FIX_HEADERS.csh is a script I hacked together to
do some of what install is supposed to do (just the parts I
need to build IRAF -- and it works when install doesn't always
seem to. Install is trying to do a bunch of other stuff that
really only makes sense for installing the whole package on
the user's machine, which I think is why it doesn't work for me).
HOW TO INSTALL THE RESULTING PACKAGE
Well, you probably know this, but, get root, then:
dpkg --install iraf_2.12-1_i386.deb
It doesn't install cleanly, yet -- I still get the error about the
doc-base stuff:
samwise:/cdimg/terry/iraf# dpkg --install iraf_2.12-1_i386.deb
Selecting previously deselected package iraf.
(Reading database ... 114937 files and directories currently installed.)
Unpacking iraf (from iraf_2.12-1_i386.deb) ...
Setting up iraf (2.12-1) ...
cannot open dhelp file '/usr/share/doc/iraf/html/.dhelp': at /usr/sbin/install-docs line 559.
dpkg: error processing iraf (--install):
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
iraf
And ...
dpkg --status iraf
Package: iraf
Status: install ok half-configured
...
Advice and/or help on improving this is hereby solicited. ;-D
I'm very happy to have succeeded in getting this far, but it's
clear that a bit more work is needed. I will still be working
on it, but I'm hoping that "more eyeballs" will make the
"bugs shallower". And at this point, it's not so much bugs,
as policy direction that's needed, and I don't know enough about
either Debian packages and policy or about what exactly IRAF,
noao, tables, and stsdas are going to need to build to be
sure what the right answers are.
Reply to: