[Bug 326421] Review Request: xmds - the eXtensible Multi-Dimensional Simulator

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: xmds - the eXtensible Multi-Dimensional Simulator


https://bugzilla.redhat.com/show_bug.cgi?id=326421





------- Additional Comments From pertusus at free.fr  2007-10-17 05:22 EST -------
(In reply to comment #4)

> Yes, it can be somewhat confusing.  I'm hoping that the next xmds release will
> be easier to package.  Hopefully we can merge some of your comments into the
> trunk and so make both of our lives easier.

Sometimes it happens that upstream sources cannot be packaged as-is
and that the reviewing process points out issues in upstream
and that a new version is needed for proper packaging.

> Corrected.  I've also added a patch for Makefile.in.  I *believe* this patch
> works, as it is a bit of a hack; unfortunately the last person to release xmds
> had a much older version of the autotools package than I do and consequently the
> changes between the different autogenerated Makefile.in's makes the differences
> not patch cleanly.  

To mitigate this issue, you can use older autotool versions. There
are many autoconf and automake version in fedora, and using the
one that matches helps doing patches that can be reviewed.

> The patch I've supplied should work I hope.  Like I
> mentioned above, hopefully the next release of xmds will be easier to package.

I am beginning to think that a new release will be a requirement,
but it is not completly obvious either.


> I've added the pdf docs (which is all that gets released now; we used to release
> the LaTeX sources as well...  Maybe it'd be better to merge the two back
> together again).

What is the license of the pdf?

> sufficient.  In the current xmds trunk there is more reference to Octave, but
> for this package I don't know if the extra effort is worthwhile.  Maybe I'm just
> hoping that xmds-1.6-4 will get released sometime soon....

Hoping that it will be named xmds-1.6.4 ....

 
> This means, unfortunately, that one can't use MPI (fftw2 handles MPI, but not
> fftw3, although it's coming).  

Right, this is a good reason to keep fftw2.

> Actually, this leads me to a point I'd not
> thought about until just now.  MPI is optional in xmds, but it needs to be
> turned on at configure time.  How does one handle this in a package such as rpm?
>  Should two packages be maintained?  One with MPI support and one without?

In general it is best to have all the possible features. But
in the case of mpi, this is really 2 different programs, so there
is a need for a separated subpackage. You can have a look at 
paraview which has a separated paraview-mpi subpackage. The -mpi 
subpackage may be added later.


> Does this mean that I need to add something like:
> 
> %package devel
> Provides: xmds-static = %{version}-%{release}
> 
> to the spec file?

No, the library should be in the main package. What would be better,
however, would be to install the library in a subdirectory, such that
it is not in the linker path. So install it in
%{_libdir}/xmds/lib....a

and modify apropriately the link command.

Similarly, the include files should be in a %{_includedir} 
subdirectory.


> be honest, I don't know why we use a library at all, that was added long after
> my time, I've just only recently become involved in a more maintenance capacity).

Having code generated and an internal library seems completely
right to me. There is another example in fedora, this is what 
gcc does.

You should also read
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.