>>>>> "RH" == Raphaël Hertzog <hert...@debian.org> writes: RH> Source: gr-fcdproplus RH> Severity: wishlist RH> User: de...@kali.org RH> Usertags: origin-kali
RH> Hi, RH> it's really not clear that 0.0.1.2.1edbe52 is actually uptsream version RH> 3.7 plus some commits... due to this another Kali developer packaged RH> a new upstream version as "3.6" when in fact the version in Debian was RH> up-to-date. RH> Please pick a version based on the upstream version: I suggest RH> 3.7+<date-of-git-snapshot> and including the git commit in the changelog RH> is enough, there's no need to stick it in the version itself. RH> Since Kali actually has version 3.6 of this package, I would appreciate RH> an upload bumping the version of the package so that the Debian package RH> again takes precedence over the Kali package. RH> Thank you in advance. RH> PS: For projects where upstream provides absolutely no version, it's best RH> to use 0~<snapshot-date>. That way it's clearer that we have no version at RH> all. Yeah, so I pulled version information from the top-level CMakeLists.txt file: set(VERSION_INFO_MAJOR_VERSION 0) set(VERSION_INFO_API_COMPAT 0) set(VERSION_INFO_MINOR_VERSION 1) The shared library has the default "ultra-zero soversion". The 3.7 floating around refers to the version of gnuradio supported. Now, I could just create a Debian package with a version 3.7+20140121 - but I'd like to include the upstream author Volker Schroer in this conversation. Here is my current plan: Change the name of the Debian source tarball of gr-fcdproplus to reflect version 3.7: mv gr-fcdproplus_0.0.1.2.1edbe52-2.debian.tar.gz gr-fcdproplus_3.7.debian.tar.gz (This tarball is just generated by the current git master HEAD of 1edbe52) Create a patch to CMakeLists.txt updating the 0.0.1 to 3.7.4. This patch I can submit for inclusion to github https://github.com/dl1ksv/gr-fcdproplus so that other distributions can package the well-known version. Create local Debian packaging patch that would set the SOVERSION to 3.7.4 when building with gnuradio 3.7.4. (I do this for the Debian gnuradio packages as well.) This means the library binary package name becomes libgnuradio-fcdproplus3.7.4 . (And it will change when building against newer gnuradio versions. I'd rather such SOVERSION management not go to github, to keep official Debian package libraries from conflicting with pybombs or build-gnuradio script local builds. FYI one of my favorite things to do is make a Debian source package tarball directly from a git tag release version. When I make updates of Debian packages based on that version, I will incorporate the patch series from git (git format-patch tag..HEAD) into the revised Debian package. As an example, gnuradio: Debian package version git version (git describe) 3.7.3-9 v3.7.3-37-gaffda0b 3.7.3-4 v3.7.3-20-gb0dce1e 3.7.3-3 v3.7.3-18-gb1855f7 3.7.3-2 v3.7.3-17-gc3ef245 3.7.3-1 v3.7.3 That's how I get bug fix git commits into Debian packages without waiting for the next upstream release version, often the right thing to do. So hopefully both Kali and Debian can follow version decisions of upstream - and now I hope Volker Schroer has a better idea of how we distribution folk like to handle release versions. Feel free to email me about versioning decisions for gr-fcdproplus, both in terms of top-level CMakeLists.txt parameters and git tags, and I can bounce back a list of pros and cons from the point of view of packaging. Hope that helps, -Maitland P.S. gnuradio 3.7.4 is stuck in NEW, there may be a few issues that need to be resolved in gnuradio before uploading Debian gr-fcdproplus packages becomes a priority again. P.P.S. Yes, I'd be interested in seeing gr-ax25 and gr-display also available as Debian packages, especially if they are working reasonably well with the current gnuradio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
