Re: gEDA-user: new SuSE rpm packages for gEDA related programs

[Werner Hoch <werner.ho@xxxxxx>]

Hi Stuart,

On Sunday 10 September 2006 14:08, Stuart Brorson wrote:
> Thanks for doing all this! FWIW, the folks at Fedora Extras are also
> creating RPMs for Fedora distros.  Are SuSE RPMs and Fedora RPMs the
> same?

Well yes and no. The package dependancies are sometimes different. Then 
there are some distro specific rpm-macros. Or just different library 
versions.
e.g. fedora has zlib and zlib-devel while SuSE has both parts in one rpm 
package. Different package names for the fortran compiler, even between 
different versions of one distro. And so on ...

It's possible to write spec files (with lots of %if, ...) that are 
distro independant (and thus create distro independant source rpms) but 
the binary rpms may be different.

> W.R.T. XSpice, yes I think you should enable the XSpice stuff by
> default.  The devil is in the details, however.
>
> The XSpice stuff
> includes the binary file spice2poly.cm, which implements the ability
> of ngspice to read models with the POLY construct. The POLY construct
> appears very frequently in vendor SPICE models, and is therefore
> pretty important.  Without it, we will be inundated by hordes of
> newbies who try to run ngspice on vendor netlists, only to have the
> program error out when it tries to deal with a POLY.
>
> The problem is that the spice2poly.cm binary isn't currently built by
> the Makefile.  Rather, it appears that ngspice simply distributes a
> binary built long ago -- perhaps, even, by me.  This binary
> works for 32 bit x86 machines running Linux, but will likely choke a
> PPC or a 64 bit system.  I don't know this for sure, but would bet
> that it will happen.

Mmhh. Do you have a simple simulation example that uses spice2poly 
features?

> The real fix is to rebuild the program for each machine architecture.
> This means that the Makefiles must be fixed to generate binaries from
> code models.  This may require a non-GNU pre-processor; I have become
> hazy on the details.  Fixing this situation is an open issue, and
> would profit from some volunteers working on it.
>
> Meanwhile, I'd suggest you *do* --enable-xspice for 32 bit x86 RPMs,
> but if you are also creating PPC and 64 bit RPMs, don't include
> XSpice for them.

Ok. I'll enable it the next time. But I would like to play with the poly 
stuff on my 64 bit box too.

> > I'm not sure whether the name should be "ngspice version rework17"
> > instead of "ng-spice-rework version 17".
>
> Use ng-spice-rework version 17.  The name of the desired package is
> "ng-spice-rework", and it is at version 17.

That was my idea too. But I saw fedora packages with the package name 
"ngspice" "rework-17". I will keep the current name, thanks.

regards
Werner


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user