Hi Bas >> - UI plugins (_cvpcb.kiface, _eeschema.kiface, _gerbview.kifacem >> _pcb_calculator.kiface, _pcbnew.kifacem _pl_editor.kiface) are currently >> installed to /usr/bin. Should I report this upstream and request they be >> installed to /usr/lib/kicad instead? Or write a patch specifically for >> Debian? >> They are dynamically loaded libraries and not executables, so in my opinion, >> they should definitely not live in /usr/bin. > > Yes, both. Report upstream and patch it in Debian until they fix it. > /usr/bin > should only contain executables, nothing else.
I reported the problem upstream, but it looks like it will be addressed post-release as it's not a critical issue. Fixing it with a Debian patch will require some insight into the KiCad plugin loading code, which I do not have (yet). If someone could point me in the right direction (i.e. which sources/makefiles to patch), that would be very helpful. > Python programs look in the directory of their executable for private modules. > I've seen packages solve that by installing them to /usr/share/packagename/ > and > making a symlink from /usr/bin to there. That works because Python will > dereference the symlink when checking in which directory the executable is. > KiCAD probably doesn't do this, so in that case that approach doesn't work. You're still referring to the plugin locations, yes? There are a bunch of example Python scripts shipped with KiCad, which are currently installed into /usr/share/doc/kicad/scripts and not symlinked to /usr/bin. I don't think it would make much sense to do so, as they're more of an exemplary nature. >> - Would it be better to pass -DCMAKE_INSTALL_PREFIX=/usr to cmake, so all >> built binaries use /usr/* for their data paths by default? > > I am not familiar with cmake, but most likely, yes. Already done. Works better than manually redirecting all paths, IMHO. >> - Should the libraries be moved to a new package, like kicad-libraries >> instead >> of kicad-common? They have become quite large, and the Github repository >> seems >> to be updated regularly. This also begs the question if such a package should >> be built separately from kicad. > > I don't know about this. What is the purpose of kicad-common? You mean there > should be a new source package, so they can be updated without triggering a > KiCAD rebuild on the buildds? That sounds reasonable. kicad-common previously contained all the libraries (symbols, modules and 3D packages), icons, file type associations, examples, i18n, scripts and templates. i18n and all the libraries live in their own repositories now, and they are updated independently from the main KiCad code base. So, stuffing the libraries into kicad-common package will tag them with the main KiCad package version, which does not accurately reflect their actual revisions. > If you're packaging the upstream release, you should use the version without > revision. If they are preparing for the release, so you are packaging a > checkout of code that will be released at some point as 4.0, you should use > 4.0~revision (which can be called whatever you want, as long as it is > monotonically increasing). Using ~ instead of + has the effect that it sorts > before "4.0", so when that is released it will be the newest version. > > If you're packaging a checkout which is based on the released version, you > should use + (or at least not ~), because then your version should be greater > than "4.0". Ah, that is a very good suggestion. I'll incorporate it. If you would like to help, you can check my packaging scripts at the github link I posted previously. Note that compiling KiCad takes a while, and partial rebuilds do not work very well. On the other hand, parallel builds are supported, but there may still be bugs in the kicad-docs part. Upstream is working on that.
signature.asc
Description: OpenPGP digital signature
