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: contributorI 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: noneare you all just going to bikeshed?
-
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: contributorSo, 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
This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 03:15 UTC
More mirrored repositories can be found on mirror.b10c.me