Re: IRAF Deb -- first pass
On Wednesday 24 September 2003 07:13 pm, Zed Pobre wrote:
> On Wed, Sep 24, 2003 at 06:31:35PM -0500, Terry Hancock wrote:
> > My package installs into /opt/iraf/iraf which seems to make sense
> > from the FHS standard,
> This is only correct for third-party packages. Packages that are
> part of a distribution belong in /usr, and to conform to Debian
> policy, IRAF needs to install mostly into /usr/lib/iraf, with
> architecture-independent components in /usr/share/iraf and
> user-accessible binaries (such as cl) accessable via /usr/bin. I
> previously had it installing in /usr/iraf, pending closer examination
> of the assumptions IRAF was making about where files were, but this
> (correctly) drew a bug report, and packages altering the contents of
> /opt won't be allowed into the distribution at all.
Um, basically, I think we're going to get into a serious conflict here,
or else this just means IRAF will remain a "3rd party package." The
thing is, it just does not make any sense to break IRAF up like
that -- it completely defeats the purpose of packaging it, because
it violates the users' expectations of it.
Where you put IRAF is negotiable, but how it is internally structured
is not. I pushed that to what is probably its absolute limit by moving
the tapecap and external package definitions to /etc (the symlinks
remaining in the IRAF tree make this tolerable).
Please remember that I have time to package these things because
I'm paid by users to keep it working, and packaging it for Debian
happens to be a good way to do that. But I can't betray their
interests just to satisfy some procrustean 3rd party policy. IRAF has
a particular structure that it needs to keep to satisfy its users, and
to make it network-installable, etc. I can't just tear it apart and
expect that all to keep working, and the users wouldn't trust it if
I did. They'd just ditch it and use an alternative source. Which would
make this a phenomenal waste of my time!
Besides, IRAF is older than Debian, I think its design has seniority. ;-)
> The /opt and /usr/local areas are for the system administrator to
> play around with, and even if he or she has "apt-get dist-upgrade" in
> a cron job, nothing that Debian packages do should ever affect the
> files stored there.
Well, the FHS says /usr/local is for the sysadmin, and opt is for
3rd party packages.
IRAF is not alone in being package-oriented, either: AIPS, AIPS++,
and CIAO will all insist on their own structure (and I get to do them
just as soon as I finish with IRAF). I think there are enough such
packages in the world, that Debian policy ought to have room
for them.
I'll think about it some more, but I'm not convinced that the concept
of breaking it up into /usr/share, /usr/lib, /usr/bin can work. At best,
we might be able to put everything under /usr/share/iraf and use
symlinks to satisfy the policy.
> No, x11iraf consists of half a dozen binaries and manpages that
> should go in /usr/bin and /usr/share/man/man1 respectively. The
> x11iraf packaging is comparatively easy; the only difficulty is in
> stripping out the libraries that were provided and making sure it
> works with whatever is in unstable.
That might be acceptable -- conventions regarding these packages
are much looser, and they are useful in their own right.
> > 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.
>
> Examine the debconf stuff that I did for my previous IRAF package.
> It basically bypasses the installation scripts entirely and replaces
> them with debconf questions that can be answered before a bulk
> installation takes place. What the install script does wasn't all
> that complex, so it was more tedious than difficult to reimplement
> it. Actually running the install script after you allowed debconf to
> handle things would damage the installation, however.
Will do -- it sounds like I won't have to do very much at all to use them.
Which is a real service -- thank you!
> > 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.
>
> If the stsci is under a free software license, I would suggest
> merging it, unless it is useful in its own right. If it is, then it
> can be packaged separately, and the resulting binary package listed as
> a Build-Depends entry for the IRAF source packages that need it.
I don't think that's really such a great idea. IRAF has dozens of packages,
these are just a few. What really bothers me about this is that STScI and
NOAO have separate release schedules. So I think they should remain
as separate as possible.
You should think of this as being analogous to Python w.r.t. to Python
modules, for example -- a core package with lots of add-on 3rd-party
components. That one of them, "noao" happens to be maintained
by the same folk who maintain the core is kind of coincidental (even
though they've long been bundled). Actually things didn't get complicated
until tables was used in the noao package -- and I think Mike was
telling me that this is a source-dependency, but not a binary one.
> It doesn't really matter that csh is inferior as long as it does
> what it needs to do and doesn't compromise security. Adding a Depends
> on csh is only a minor nuisance, and I wouldn't worry about it.
Okay. Maybe a "Build-Depends" on Python would be okay, too?
I know Python better than either shell language, and the STScI
packages will depend on it anyway, as they provide a python shell
for IRAF called "pyraf".
> If you create a properly named orig.tar.gz and use the debian
> tools to create a diff and a dsc file, you can cut it down to one
> step: dpkg-source -x iraf_2.12-1.dsc. Check the man pages for
> dpkg-source, dpkg-buildpackage, and debuild. Since one of your later
> steps actually uses dpkg-buildpackage, you should have ended up with a
> source, diff, and dsc at the end anyway.
I wasn't sure how complete .dsc is -- I wanted to show you the
iraf.debian, iraf.diffs, and iraf.overlay directories which separate
out my custom work from the main distribution. Other than unpacking
into the right directories and making sure I'm using the right versions,
the orig.tgz file is pretty much straight from upstream (although not
"pristine").
> If you require environment variables to be set before running
> debian/rules, you're going to get into fairly serious trouble. Make
> sure that whatever you need gets set from there, and that it will
> build from an arbitrary environment.
Hmm. They are used to remember targets used by th BUILD_TARGET.csh
script. This seems to work. What would tend to break this system?
> > 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).
>
> It will also generate an iraf-2.12.orig directory one level up,
> which is going to take a whole lot of space. Since all that dh_make
> does is make that and the debian/ directory, you're better off simply
> including the debian/ directory in a patch.
Yeah, it's pretty big, but don't we need that to make the diff.tgz?
> > 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.
>
> If you just want it to build the debs, but not generate a diff or
> dsc file or bother with signing, you can run "debian/rules binary"
> instead.
Thank you for mentioning this. I suspect I can use this approach to
shorten my development cycle. Building takes about 10-15 minutes
even on a very fast computer, so testing the final install steps by
just running dpkg-buildpackage was getting pretty tedious. I guess
I could just leave the build alone and test with "debian/rules install",
huh?
> I'm probably going to catch flamage from the dhelp and dwww guys
> for this, but I actually recommend that you avoid trying to deal with
> doc-base at the moment. Just make sure the html files get packaged
> somewhere under /usr/doc, and don't specify any debian/iraf.doc-base
> files or try to call install-docs manually in your postinst.
I imagine this is a fairly trivial problem, but I probably should do as you
say and then bring the doc-base back when the other stuff is working.
> Hope this helps you. I'll see if I can set aside some time to
> more closely examine your work sometime either this week or next. Bug
> me if I don't get back to you.
Sure thing. Thanks for all the help. I'll spend some more time working
with it this week, and I'm sure I'll be adapting your debconf scripts, as
that seems to me to be the main thing missing.
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Reply to: