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
TARGET=/usr/share/iraf
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
done
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 are
> 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
> <http://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 the
(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, one
> usually would install iraf, iraf-noao, iraf-doc, iraf-noao-doc and
> (iraf-vo, iraf-vo-doc).
Someting like
iraf
iraf-common
iraf-noao
iraf-noao-common
ifaf-vo
iraf-vo-common
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
> libraries.
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
/usr/include/iraf/, right?
> And x11iraf (where xgterm lives) has to be another package. And we need
> .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.
Best regards
Ole
_______________________________________________
Fedora astronomy mailing list
astronomy@xxxxxxxxxxxxxxxxxxxxxxx
http://fedoraproject.org/wiki/SIGs/Astronomy
https://admin.fedoraproject.org/mailman/listinfo/astronomy
