This approach creates many problems for users. If you do not embed the library, then the dependencies break, you have to compile them yourself in a separate non-system folder or use the entire zoo of various packages in the form of flat packs, snaps, etc.
No it does not as long as you walk on the way that is intended. And the intended way is to use the package manager of the distro you use together with the right archive resources.
For Ubuntu various PPAs are available, but if you use these you are out of the official distribution! These are not a core part of an Ubuntu release! PPA is an abbreviation for Private Package Archive. You need to understand basically how PPAs do work and what downside this can bring in.
The issue you mention by linking to #4 is a typical packaging issue, itâs up to the maintainer of a package to set the correct restrictions and dependencies. Welcome to the world of PPAs.
In this case, the packaging problem is not directly related to the installation from the PPA. Conditionally, if I take two ready-made deb packages, a similar situation will occur with the dependence on the simulator library (conflict). The question is in installing a common simulator library for all programs. Or each program has its own built-in isolated library or it is common for all. Now we get into the crotch if you want to use Kicad then you will not be able to use its library for other simulators. When installing Kicad with a built-in library, I cannot use this library as a common one, I think the idea is clear, but this is already a repetition)
The easiest way, as it seems to me, would be to split the PPA into 2 independent kicad and a simulator, where kicad uses the simulatorâs system library, and not, as it is now, integrated into its PPA IMHO
Here is an example of this approach Install package home:ra3xdh / qucs-s
Do you know who maintains the KiŃad PPA repository? Where can I write a request? Git Lab Git Hub Forum? Is there a chance that the escort will see this? Or has he already seen it?)
I tried the option on a virtual machine, yes it was updated, but it pulled all the other libraries not related to kicad, as a result half of what worked before broke
Thatâs not supposed to happen. And it doesnât do that on my system. Kicad pulls in around 20-40 packages â all related to kicad. You can install with
apt install --no-install-recommends kicad
then fewer packages are installed and only the strictly required dependencies are pulled in. Or maybe your system is configured to also install the suggested packages. A vanilla Debian installation doesnât do that. So thatâs unrelated to kicad and OT with regards to this thread.
Thatâs not a very specific description of what went wrong. If installing a package from the stock respositories breaks stuff, report a bug to the Debian bug tracker. Thatâs all I can say.
BTW: Kicad 8.0.8 (and libngspice0 44.2 for that matter) are available now in all distributions (stable-backports, testing and sid).
As others have mentioned, kicad uses the ngspice shared library (libngspice0). If you look at the availability of libngspice0 44 in Debian, youâll see that itâs available on testing and sid and backports. So installing kicad 8.0.8 e.g. on testing or sid will pull in libngspice0 44.2 by default. See my screenshot posted earlier.