Hi, adding some notes here for the planned Debian packaging. Jean-Samuel emailed my some days ago already about his planes and we have tried to stay in contact about a consistent packaging schema between Ubuntu and Debian which makes absolutely sense in my eyes.
Am 15.01.2018 um 09:40 schrieb Jean-Samuel Reynaud: ... > *New package situation:* > > So I have reshaped packages: > > kicad-library > kicad-library-footprints > kicad-library-packages3d > kicad-library-symbols > kicad-library-templates I've agree on those new needed binary packages, which will also introduce the depending new source packages. > kicad-library is a meta package. It had a dependency (recommend, not > strong) to each others. In terms of Debian and Ubuntu there is only Recommends and Suggests available. The difference between both is simple that a Suggests will never be installed automatically, a Recommends will be installed unless the user is turning this globally off (default in on) or while calling 'apt install' by the option '--no-install-recommends'. There is no strong or soft recommending. I suggested to use 'kicad-libraries' as the package name and make 'kicad-library' a transitional package. > The version of this package will be prefixed with a "1:" to put it on > the front of older version of kicad-library. This is not needed in my eyes. The sense of a epoch version is something different [1]. As long as the new version number for 'kicad-libra[y|ies]' is greater than the previous one the update will work as wanted, the new version is overwriting the old package. But I haven't looked at the existing PPA packages from Jean-Samuel in detail until now. > kicad-library-packages3d own all 3D. This package have a large size (~ > 330M, 4G on disk) . It will have a recommended dependency to > kicad-library-footprint > > kicad-library-footprints own all footprints > kicad-library-symbols same with symbols > kicad-library-templates same with ... templates ;) > > All kicad-library-* packages have a conflict constraint to > kicad-library << 1:0.1 and kicad-common (as before). > There is also a recommended dependency to kicad-library >= 1:0.1. > > This last point will avoid cross installation between kicad-library > version since those packages are be incompatible (shared files...). As written, not needed as long the new version is greater than the old one, and this is a hard requirement. If you use epoch you allow some smaller version explicitly. > *Migration* > > No specific action are required. Update will do his jobs automatically. > Anyway you can now install only one package if you want limit disk > space/download time... > > If you experience any errors, please let me know ! Main error that can > be found is one file in two packages (file conflict)... Ubuntu has no piuparts testing? In Debian there exists piuparts which is testing several constellations of possible upgrading a package. I hope I can start in the next weeks to modify the existing KiCad package in Debian to adopt Jean-Samuel package suggestions and uploading the new packages to NEW. My work on NGspice is no hard dependency foe KiCad but Want to get this out of the door before starting new things. If someone want to jump on to the packaging just ping me. Some experience with the Debian packaging would be appreciated! I will also travel to FOSDEM, so if someone want to do some face 2 face talking also just ping me. ;) [1] https://www.debian.org/doc/debian-policy/#version [2] https://piuparts.debian.org/ -- Regards Carsten Schoenert _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp