Re: RedHat RPM issues with amaya 8.1b

On Wed, 1 Oct 2003, Irene Vatton wrote:

> On Tue, 30 Sep 2003 11:37:40 -0400 (EDT)
> Nico Kadel-Garcia <nkadel@merl.com> wrote:
> 
> > 
> > 
> > Overall, Amaya is a nice freeware tool. However, the .spec files
> > included with it need some work as described below.
> > 
> > 	1: amaya.spec refers to the wrong version of amaya and
> > prevents the "rpmbuild -ta amaya-src-8.1b.tar.gz" from working. (I've
> > got a patched .spec for this).
> 
> amaya.spec generates the motif version. We didn't generate this version for a
> long time and I agree the file amaya.spec was not updated.
> We have an amayagtk.spec that generates the gtk version and an amayagl.spec
> that generates the gl version.

OK, here come my current updated versions, with all the other patches
I mentioned., and without the gl/gtk run-time selection yet.

Do you want the OpenMotif, GTK or GL versions to be the default.

> > 	7: Some of the spec files are noted as including the amayadoc
> > tarball. Should this be re-integrated into the .spec, or is the
> > documentation in the source tarball include a recent enough version of
> > amayadoc? There are lots of differences between amayadoc's contents
> > and the Amaya/doc files, so I can't assess easily which should be
> > used.
> 
> The source tarball includes the English version of the documentation.
> The tarball amayadoc includes French, Spanish, German, and in the future
> Russian versions of the documentation.
> Probably we'll have to generate a separate rpm.

Got it. It's possible to build a spec file that builds a separate
documentation package: it does make the SRPM larger to include such a
document set.

Which would you prefer to include? And where would it go relative to the 

> > 	8: The source tarball insists on including the redland and
> > libwww tarballs as well. This goes against the basic idea of modular
> > RPM compilation and installation. There are good RPM's available for
> > both redland and libwww, and I don't see why you insist on including
> > it in the source tarball for amaya.  (I won't pursue this unless
> > others want it.)
> 
> Amaya uses standard libraries when it's possible, but it needs
> specific versions of libwww, redland and expat.

Got it. That's a shame, but I do understand the requirement. It's not
difficult to write spec files that would use 3 distinct tarballs
instead of just the one large one, with specific versions, so you
could update one package instead of having to build Amaya tarballs
with all 3. Let me know if that would be useful to you.

> > 	9: Compilation for "gl" and "gtk" versions could be done as a
> > ..spec option, rather than using. This would allow "rpmbuild -ta"
> > compilation with a build-time flag set, and only one .spec file to
> > maintain. (I won't pursue this unless others want it.)
> 
> This is probably a good idea but I'm not enough expert in rpmbuild 
> to do that. Any patch available?

Give me a week, I'm kind of busy and I prefer to compile-test .spec
files before publishing them.

> > 	10: Because Amaya is system dependent set of binaries and
> > configuration files and *NOT* a sharable set of tools, with its own
> > documentation and libraries not integrated into
> > "/usr/local/{lib,bin,include,share}" compilation, I think it should
> > really be in "/opt", not in "/usr/share". But that's a matter of
> > taste. (I won't pursue this unless others want it.)
> 
> This was due to the history. We installed several versions of Amaya
> on the same server. All these versions were able to share 
> configuration files and documentation.
> It's still possible but it's not the current approach.

Hmm. So would you prefer now to have it set aside in its own location,
such as /opt/Amaya, or merged more gracefully into the standard
/usr/share locations? Merging it might require some significant
Makefile code changes.

> > amaya_gl compilation is still failing for RedHat 8.0, but I'm
> > looking into that now.
> 
> We already generated the gl version on RedHat 8.0 with amayagl.spec.

Good. I haven't gotten it to compile, I'll post the results later today.

-- 

				Nico Kadel-Garcia
				System and Networks Administrator
				Mitsubish Electric Research Lab
				<nkadel@merl.com>