-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone,
On Fri, Sep 18, 2015 at 04:20:15PM +0100, matt.notting...@zen.co.uk wrote: > Going by the current blockages due to the GCC5 transition, even if you > had it packaged now, it wouldn't be available! Yes, I recently updated my system and had to remove KiCAD to get the update through. Now it's uninstallable. If there's anything I can do to speed up the process of getting the new package in, let me know. Probably no longer relevant, but here are answers to some questions: On Wed, Sep 16, 2015 at 04:25:31PM +0200, Gregor Riepl wrote: > - 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. 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. > - 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. > - 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. > - The KiCAD developers have designated their new stable release as 4.0. Debian > currently uses a date+revision version scheme. Should the Debian versioning be > changed to reflect this? What is the proper way to do so? 4.0+bzrnnnn is what > I currently use. Good/bad idea? 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". I thought their code was on github? Using "bzr" sounds strange in that case; "git" would make more sense. Thanks, Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWGUQ2AAoJEJzRfVgHwHE6dSAP/1aPWixrLWaBZxE9N2GhOlG8 BFLBMbpP+IA65Y1MIKT9OnElfHi7bthmRhW3qCKMJiq8ypN/0qCzLtXdo69FW1IH tajMozgER1eVZNKw4+i9vVUOzmqagpyAVzEfOIRVfrx/B4fqmIg66gMOfrPrdN1a 3R7sX0s9rev6WbV2QRsGJGxkUpx7lSnUMRrEXXkvw+XcTQtsKggn5RNEVxUteQsQ ndM0ZYX8QFbGmr8pfK5lgAEv6dvAIEbfGbBm8Csoa8Z1oVZv4wEBxBdDeKL7hbjs 08N2BifPiotMzoD7hvIpkFmLODj62X/iYO648YJP41QQ2Hmg/JlVuEFIOUwhYt/N eelzmhEEFK/4NK/d7+x6yYjtqUrBhGGYa+O9kDsZHwbq3RwDMPi2FYfLOkqNFlB2 rEtfRDOlBhhwNDtVl5eyPMI+flppCUjQsk51X2UHvlXtMYYJij7p+dA5rbNiY+L9 KmHVDOH1c7kEO0qHrQ4rGj2LEHSRrHDHleapoQbhGkzhHgsRTyytN617sjA5sZpF hDS2AuNWL6oYsu5tvqRIjstwjBnlzoxmIiLhoMxK8Rmjc2t6d4h5rw+9WOov+2Qj 1rKcsKdzb2hxfW8yaF1yfA3slBybfoWwFLhqEJg9370yMB0fI9fT+CBF+pbfvLh4 Vqw3OImoXdbnKVckJ+wq =2J3Y -----END PGP SIGNATURE-----
