[Pkg-electronics-devel] KiCAD packaging bug

[Carsten Schoenert]

Hello Nick,

Am 30.10.25 um 04:06 schrieb nick at ndcode.org:
> hi Team,
> 
> I've been dealing with a frustrating issue in my KiCAD simulations -- I
> had used some digital electronics relying on the Xspice extension to
> ngspice, but the simulation would not run. It turns out that the KiCAD
> version I'm using didn't include ngspice as a dependency, only
> libngspice0. See this:

SNIP
Yes, that is intended. To be functional the kicad application is only 
needing the library of ngspice, but not the files that you in your case 
are relying on. So no, the kicad binary package should not depend on 
more other additional packages provided by src:ngspice

> Because of that, critical files weren't installed on my system. At least
> the following files are needed for the Xspice simulations to work:
> 
> /usr/lib/x86_64-linux-gnu/ngspice/digital.cm
> /usr/lib/x86_64-linux-gnu/ngspice/xtraevt.cm
> /usr/lib/x86_64-linux-gnu/ngspice/table.cm
> /usr/lib/x86_64-linux-gnu/ngspice/spice2poly.cm
> /usr/lib/x86_64-linux-gnu/ngspice/xtradev.cm
> /usr/lib/x86_64-linux-gnu/ngspice/analog.cm
> /usr/share/ngspice/scripts/spinit
> 
> Doing dpkg --listfiles ngspice I see that all of these files are
> installed by the ngspice package, not libngspice0. I suppose the issue
> could be partly addressed by making ngspice a "recommended" package, but
> given the error messages are extremely cryptic (and there are many other
> issues with getting a digital simulation to work, due to confusing and
> partially implemented features in the KiCAD simulator) it would be
> better to make it a hard dependency.

No, our (packaging) policy is defining what these fields are for. [1]

> Depends
> This declares an absolute dependency. ...
> 
> The Depends field should be used if the depended-on package is required
> for the depending package to provide a significant amount of functionality.

This part isn't true for the package ngspice in relationship to kicad.

> Another approach might be to ask ngspice packagers to move these files
> so they are always available when libngspice0 is available.

This make also no real sense, the libngspice library doesn't need these 
file to work correctly, a library can't depend on other standalone 
binary files, but mostly and usual on other libraries and their symbols.

> But making ngspice a dependency would be a better approach in the
> short term.
A dependency is too strong in my eyes (you are the first person who is 
coming up with such questions since I maintain KiCad and ngspice), even 
a Recommends isn't the right thing maybe. I agree to add ngspice into 
the Suggests field.

ngspice has an installed size of 30MB, that's not that small anymore. 
Having these .cm files in the ngspice package is a compromise as they do 
not fully belong into that package by there nature, otoh the FOSS 
simulation area is heavily fractured due the mostly proprietary code 
they derived from and no common standards where such files should get 
installed. That makes it hard to provide one ore more generic packages 
with the simulation files.

For now I think a Suggests and some further information in the long 
description of the kicad package is the bets way.

PS: Next time please submit a bug report about your issue(s), bug 
reports will land on this mailing list too.


[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

-- 
Regards
Carsten