kifaces should be installed to /usr/lib/kicad not /usr/bin

[Gregor Riepl]

I am currently packaging the 4.0 release candidate for Debian, so the packaging scripts will be ready when KiCAD 4.0 releases.

There's something I noticed: All the _*.kiface files are installed to <prefix>/bin - which I do not think is an appropriate place for them. Only executables should go to /usr/bin, but these are dynamically loaded libraries. Trying to execute them on Linux will result in a segfault.

I think they should be installed into <prefix>/lib/kicad/kiface or similar. Can you change this for 4.0?

[Chris Pavlina (pavlina-chris)]

I cannot even begin to fathom why the decision was originally made to put them in $prefix/bin. Clearly by someone who does not understand the Unix/Linux filesystem structure. It's not what I'd call a release-critical bug, but FFS, it's something we really ought to fix. It's just going to piss off every package maintainer ever, and violate every distribution's standards.

[Nick Østergaard (nickoe)]

I agree this is an unfortunate setup, but I don't think this should block the release, although it would be nice to get sorted out.

[LordBlick (lordblick)]

I would like to stipulate, in 64-bit systems, /usr/lib64 should be taken into account, that wouldn't be fixed path…

[Wayne Stambaugh (stambaughw)]

Will fix after the stable release just in case.

On 9/22/2015 12:19 PM, Nick Østergaard wrote:
> I agree this is an unfortunate setup, but I don't think this should
> block the release, although it would be nice to get sorted out.
>

[Nick Østergaard (nickoe)]

I guess this can now be fixed. With the introduction of the libkicad_3dsg.so stuff we can easily move the kifaces, I think.

[Chris Pavlina (pavlina-chris)]

I agree 100%. Installing sofiles into /usr/bin is just dodgy, I'm surprised the distros are letting us do that tbh - now that we've definitely solved the problem of loading them from the proper place IMO there's no excuse not to put them where they belong.

[Wayne Stambaugh (stambaughw)]

Maybe the distros don't realize what the kiface files really are. The
only drawback to this is now library versioning comes into play when
multiple versions of KiCad installed. AFAIK, the kiface files are
currently not versioned. I'm OK with this change but we will have to
begin versioning the library files carefully. Making the library
version match the release version makes the most sense to me. It will
be up to the developer to handle versioning of development of the
development builds of the libraries.

On 5/12/2016 10:22 AM, Chris Pavlina wrote:
> I agree 100%. Installing sofiles into /usr/bin is just dodgy, I'm
> surprised the distros are letting us do that tbh - now that we've
> definitely solved the problem of loading them from the proper place IMO
> there's no excuse not to put them where they belong.
>

[Gregor Riepl (onitake)]

IMHO, this should be implemented as soon as possible, as KiCad 4 is stable and has made it into various distributions.

I don't have a strict opinion on versioning, but it's probably a good idea to decide this now rather than later. Perhaps it makes more sense to implement some kind of API compatibility tag instead, to open the path for external plugins. What do you think?

[Jeff Young (jeyjey)]

Did anything ever happen with this?

[Wayne Stambaugh (stambaughw)]

Not yet but given that users want to install multiple versions of KiCad,
fixing this will not be as simple as changing the install path. Library
versioning would have to be properly handled which could be tricky
across all of the supported platforms.

On 4/6/2018 8:03 AM, Jeff Young wrote:
> Did anything ever happen with this?
>

[Gregor Riepl (onitake)]

I don't think this should be too difficult to solve.
For Windows and macOS, this virtually a non-issue, as a single software version is usuall bundled together on these platforms.

On Linux and other Unix-like operating systems, it should be sufficient to tie a plugin to a certain KiCad release version. The main program should then use a library path such as /usr/lib/kicad/5.0 - with a fallback to /usr/lib/kicad if no plugin can be found.

If one wants to get fancy, the host triplet could be added as well (like in /usr/lib/i386-linux-gnu/kicad/), but that is rarely useful.

[Wayne Stambaugh (stambaughw)]

I took a look at this and it's not as easy as I thought it would be. It will require some changes to the so naming code to handle multiple versions. I'm going to defer this to after the stable 5 release so we can do some thorough testing before back porting it to a v5 point release.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1833