Debian package #14

pull genjix wants to merge 1 commits into bitcoin-core:master from genjix:debpkg changing 8 files +157 −0

genjix commented at 8:03 pm on May 13, 2014: none

$ cd secp256k1 $ dpkg-buildpackage -rfakeroot $ ls ../
debian package. 7c682ce155
gmaxwell commented at 8:05 pm on May 13, 2014: contributor

I thought bundling packaging materials was considered a bad practice?
laanwj commented at 1:46 pm on May 14, 2014: member

Distributions themselves generally don’t use the bundled packaging materials.

However, we do the same in bitcoin core (in contrib/debian), I think it is used for building the PPA.
genjix commented at 10:17 am on May 17, 2014: none

are you all just going to bikeshed?
sipa commented at 4:37 pm on May 18, 2014: contributor

I have no opinion either way. I don’t know how to review this, though. @theuni, comments?
genjix commented at 4:42 pm on May 18, 2014: none

run these commands:

$ sudo apt-get install dpkg-dev debhelper $ cd secp256k1 $ dpkg-buildpackage -rfakeroot $ ls ../

then you have your debian packages. Look at the files under debian/ - they are trivial, and should give you an idea of what’s happening.

install the files on Debian with:

$ dpkg -i secp256pk1filename…blaa.deb

List the files in package (use tab completion): $ dpkg -L secp256k1

There should be a normal lib package and a -dev one.
sipa commented at 5:53 pm on May 19, 2014: contributor

I wasn’t claiming it’s hard to test. More: I have no clue what best practices are here, so I’d like to hear some opinions.

I’m not sure I like exposing this too much already. The API will likely change significantly still, and I wouldn’t want to encourage anyone to use this for production systems…
theuni commented at 6:01 pm on May 19, 2014: contributor

Will do a quick review (and the pkg-config pull req as well) in a few hours when I have something other than this phone at my disposal.

Without looking, I like the idea of having this done so early. Thanks for doing it. If nothing else, it makes it easier for us to push to a testing ppa until @sipa is happy with the api. On May 19, 2014 1:53 PM, “Pieter Wuille” notifications@github.com wrote:

I wasn’t claiming it’s hard to test. More: I have no clue what best practices are here, so I’d like to hear some opinions.

I’m not sure I like exposing this too much already. The API will likely change significantly still, and I wouldn’t want to encourage anyone to use this for production systems…

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/secp256k1/pull/14#issuecomment-43535386 .
theuni commented at 4:24 pm on May 20, 2014: contributor

Looks ok at a glance to me. Though I’m not qualified to review the debian rules themselves.

Please remove the bug reference in the changelog, I’m assuming that was c/p from libbitcoin. Also, I trust that you’re not planning on pushing for Debian inclusion of libsecp256k1 until @sipa is ready?

Also, I suggest hard-coding the configure options for field/bignum based on the package dependencies. In this case, –with-bignum=gmp. That way there can be no accidents like “I thought it was using libfoo but it was actually using the built-in slow path”. @gmaxwell: Imo bundling is reasonable until the release is stable and accepted into Debian, at which point it should be dropped.
genjix cross-referenced this on May 21, 2014 from issue Debian package by PabloCastellano
sipa commented at 1:15 am on June 12, 2014: contributor

So, at this point I actually don’t want to encourage anyone to package it. It’s experimental, and I don’t know how the API will change in the future. Packaging implies some stability that I don’t want to commit to now.
sipa closed this on Nov 2, 2014

Contributors
genjix gmaxwell laanwj sipa theuni