Hi Sergio and all,
Am 30.05.2013 23:47, schrieb Sergio Pascual:
I completely agree on trying to coordinate efforts.
Nice to hear :-)
* Splitting into smaller packages. As all the .cl, .dat, .par, .key
files, etc are shareable between arches I agree that they should go to
/usr/share/iraf and in a differente package. Notice that there are still
a bunch of files (READMEs, csh scripts, text files with docs about
implementation, etc) that are basically not need in the running system
and could be removed.
When browsing around the iraf sources, I found several "strip" scripts
that could be converted to a "shared" install script. Something like
for j in $(find . -name \*.hlp \
-o -name \*.hd \
-o -name \*.men \
-o -name \*.cl \
-o -name \*.par \
-o -name \*.key \
-o -name \*.dat \
-o -name \*.mip \
-o -name \*.fits \
-o -path ./dev/\* \
| cut -c3-) ; do
install -p -D -m 644 $j $TARGET/$j
rm -f $TARGET/dev/tapecap.* $TARGET/dev/README
should do the job for all files needed at runtime. These are ~ 20 MB.
Speaking about arches, an ARM port would be very cool...
Yes. If you know someone with assembler experience: as.linuxarm/zsvjmp.s
is the file we need.
Regarding docs and noao and vo packages, I have my doubts. The docs
used in the internal documentation system (when you type "help" in cl).
In my experience, users type "help" all the time. Tasks are complex,
with long lists of parameters and you need the doc system to understand
what the task does. The noao package contains basic subpackages. CCD
processing is in noao.imred.ccdred Long slit spectrosocopy is in
noao.twodspec. In fact, I preloaded noao in my login.cl
just to avoid loading myself everytime I entered Iraf.
I haven't used vo, thought.
With documentation, I tend to agree -- although I can imagine that the
documentation is not strictly needed when running a prefabricated script
non-interactively (f.e. on a computing farm). However, we would not save
much if we split it.
What concerns splitting VO and NOAO: Even upstream (NOAO) splits (or
splitted) them up in their binary releases ("ib" for IRAF binary and
"nb" for "NOAO binary"). For me, it makes sense to separate between
(generic) IRAF system and the (more algorithm-related) NOAO package,
even if most people will always install them together.
Spliting said packages would mean that, to have a functional iraf,
usually would install iraf, iraf-noao, iraf-doc, iraf-noao-doc and
Alternatively, one could create "iraf-base" and "iraf-base-common"
packages that hold the base system, and an "iraf" virtual packages that
joins everything together via dependencies.
Too many packages in my opinion. I prefer just iraf for binaries and
iraf-common (for example) for noarch data.
The end-user will not need to fiddle with these packages; he would just
install IRAF. On Debian, I would create a "recommends" dependency, which
means "packages that are installed together, wich declares a "strong,
but not absolute, dependency. The Recommends field should list packages
that would be found together with this one in all but unusual
installations". I would guess the same exists in Fedora.
To have a comparison with other large package suites, look f.e. to the
"libreoffice" suite. Except for language packs, I don't know anyone who
would only install the writer -- but it is split up into lo-base, bsh,
calc, core, draw, ...
We need an iraf-dev if we want to be able to build external iraf
packages. The xc compiler should go in this package. And the headers and
Sure. Main issue for me would be to have a list of files that should be
included. Would we basically need just .h and .a files? What about
sources (.x, .c, .f)? Also, I think the header should go into
And x11iraf (where xgterm lives) has to be another package. And we
.desktop files for it.
Yes. I would, however, recommend that x11iraf also gets a separate
source package. In the moment, it is build as part of the iraf pkg, but
it has its own (independent) source tar file.
Also, I think that x11iraf is not 64 bit clean, so even if it may be
build on x86_64, it will probably crash there. Therefore it makes IMO
sense to have a separate package that builds only on 32-bit platforms
(mainly i386) -- and (for Debian) one could use the Multiarch approach
to run it.