Packaging (RPM, DEB) about jwt-cpp HOT 17 CLOSED

Do you mean something like a ppa?
Or would a deb file published on the releases page be enough?

from jwt-cpp.

I'd be happy with anything that resembles a "source package", i.e. a spec file for rpm and/or some debian/* (mostly rules). Right now the Makefile doesn't even support "install"...

from jwt-cpp.

@steffen-AEI I dont have experience with rpm (I only use debian based systems) but a make install target as well as a debian rules file shouldn't be a problem.

Regarding rpm: I will take a look at it but I'll happily accept PRs from people with more experience.

from jwt-cpp.

I added a debian directory and make install support to the makefile.
You should be able to build a debian package using a command similar to the following:
dpkg-buildpackage -rfakeroot -Zgzip -z1 -k<gpgkey> -us -uc -ui

from jwt-cpp.

The Debian part looks good at a very first glance - since there's no tagged 0.3.0 yet I'll tweak the debian/changelog a bit and build a 0.3.0~rc. Give me a day or three... (Thanks!)

BTW, to build on Debian, a rather recent libgtest-dev is required, I didn't succeed to even compile the code with 1.7.0 in Stretch. Fortunately backporting googletest 1.8.1-3 from Buster is straightforward (set compat level and debhelper minimum version to 9, basically)... so this might even work for those people still stuck with Jessie.

from jwt-cpp.

@steffen-AEI I could also exlude building and running the test cases, as they are not strictly required to build the deb and won't be included in the resulting file. There is a 0.3.0 tagged, take a look at the releases page. I did it because of this issue but it was over due for quite some time.

from jwt-cpp.

Apologies for missing 0.3.0 as I was (in a scripted manner) looking for a v${something}.tar.gz only. (Script adjusted.)

For a yet unknown reason (*), the debian/ subtree is completely missing from the tarball though, I had to add it from the git clone. BTW, I'd prefer a source format of "3.0 (quilt)" as "3.0 (native)" does not allow repackaging for multiple Debian releases (but I'd expect install dependencies to change between Stretch and Buster)...

(*) Reason apparently found: the 0.3.0 tarball contains files dated Jun 18, thus "somehow" the tagging must have happened before the commits were applied - also the Makefile is the old one, missing the install target. I'm building a patch, and bump the build number...

from jwt-cpp.

@steffen-AEI I'm sorry, the missing v in the tag was indeed a mistake.

I changed the tag name to match the old ones.

Yes the tag is the commit before the debian directory was added (aafd0b5).

I chose 3.0 (native) as I could not figure out how get it to build a deb without a tarball present.

from jwt-cpp.

After adding libssl-dev and libgtest-dev (>= 1.8.1~) to the list of build-deps, and updating the Makefile to the git head version, I could make the package build. Now that I had a closer look, it's indeed the three header files only that make up the ("binary") package contents, and everything else is just unit tests to prove those are in shape. A native package seems to be justifiable (as it's only built once, arch-indep, and the result would indeed be useful on any Debian version).

I'm now taking a shot at scitokens-cpp which requires jwt-cpp to be built... Thanks so far! (I'm not a rpm user either, but a spec file should be rather straightforward, you may check the scitokens-cpp one and use that as a template - no cmake, no ldconfig, no subpackage, things should be quite easy.)

from jwt-cpp.

Here's my version of jwt-cpp packaging, with the latest Makefile changes represented as a patch: https://hypatia.aei.mpg.de/lsc-amd64-stretch/jwt-cpp_0.3.0-0.2+deb9u0.debian.tar.xz - feel free to adapt and republish. I'll watch this space for upcoming releases.

from jwt-cpp.

feel free to adapt and republish

Thanks, I integrated them into the repository and released a new version. Take a look at v0.3.1.

from jwt-cpp.

Great! (You may just drop the additional stretch entry - which is a by-product of me building for 3 releases.) Also, in my understanding of the Debian Policy, quilt packages are supposed to have/provide a build number (to enable NMUs, givebacks, etc.), but this is absolutely minor (my scripts would add a -0 but Big Debian might complain)

from jwt-cpp.

Can this be added this to the AUR too? I would do it, but I can't maintain it if something were to go wrong

from jwt-cpp.

What if we used cpack? I am not sure what AUR stands for, so please share the full name!

from jwt-cpp.

What if we used cpack? I am not sure what AUR stands for, so please share the full name!

AUR is kind of like Deb and rpm but for arch. Usually its designed to build the packages after downloading, but since theres nothing to build here I doubt theres much difference.

from jwt-cpp.

There's way too many package mangers

from jwt-cpp.

Here is a sample of what a PKGBUILD might look like.

# Maintainer: name <[email protected]>

pkgname=jwt-cpp-git
pkgver=1
pkgrel=1
pkgdesc='A header only library for creating and validating JSON Web Tokens in C++11.'
arch=('any')
url='https://github.com/Thalhammer/jwt-cpp'
license=('MIT')
depends=('openssl>=1.0.0' 'gtest')
makedepends=('git' 'cmake>=3.0.0')
provides=("jwt-cpp")
conflicts=("jwt-cpp")
source=('git+https://github.com/Thalhammer/jwt-cpp.git')
sha512sums=('SKIP')

pkgver() {
  cd "${srcdir}/jwt-cpp"
  git describe --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//'
}

prepare() {
  mkdir -p "${srcdir}/build"
}

build() {
  cd "${srcdir}/build"
  cmake "${srcdir}/jwt-cpp"
  make
}

check() {
  cd "${srcdir}/build"
  # FIXME
  #make test
}

package() {
  cd "${srcdir}/build"
  make DESTDIR="$pkgdir/" install
  install -Dm644 ${srcdir}/jwt-cpp/LICENSE "${pkgdir}"/usr/share/licenses/${_pkgname}/LICENSE
}

from jwt-cpp.