Scott Howard [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-23 📝 Original message:On Tue, Jul 23, 2013 at ...
📅 Original date posted:2013-07-23
📝 Original message:On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn <mike at plan99.net> wrote:
> Hi,
>
> Some of us have put together an open letter to the Linux packaging
> community, outlining why Bitcoin is different to other programs and asking
> them to not patch or modify the upstream sources.
>
> Please consider signing it if you agree (I think the wording by now is fine,
> so don't edit the contents - use the comment feature if you want to though).
>
> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
>
> The trigger for this is the discovery that Debian bitcoind's got split out
> of the consensus some time in April, for reasons that nobody yet figured out
> but is presumably related to a patch (eg it uses system leveldb).
Hi Mike,
Debian's bitcoin is maintained on an open and archived mailing list
and git repo:
Debian Bitcoin Packaging Team <pkg-bitcoin-devel at lists.alioth.debian.org>
If there is a problem or question, getting an answer should be really
easy. It would be good to include them in the discussion there (I
CC:ed the list). If the upstream developers have a consensus that
distribution packaging is not in the best interest of the project,
then I personally would defer to their judgement and request removal.
I'm leaving this open for other opinions from the Debian side.
That said, let me summarize the arguments and see if we can figure out
a permanent solution:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user and the network.
Response: Is there a way to "certify" the Debian libraries? Debian
bitcoind/bitcoin-qt runs the compile test during all architectures.
MIPS has been failing recently, but no one has looked into it yet.
Perhaps it's not worth developers efforts yet, but at some point the
technology should reach a point it can be redistributed.
2) Bitcoin is new technology, so any patches have the ability of
harming both the network and user.
Response: I, and I'm sure everyone else working on it, totally agrees.
All patches are public [1], you can see that the patches are only to
the build system (except for one adding a debug message). Is there a
specific patch or bug that is problematic? This seems to be
reiterating (1) above: don't patch the build system to use libraries
that were not audited by the developers.
The two solutions are: (1) no one besides the upstream developers
compiles and distributes binaries, ever, or (2) upstream comes up with
a system where someone besides them can compile working binaries for
distribution. Most likely the best solution is to do (1) until
upstream sets up a system to allow (2).
I'm curious as to other's opinions.
Thanks,
Scott
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=tree;f=debian/patches;h=ba576f9f3ddad47a2f85dcbfb7a0b3482834f19f;hb=HEAD
📝 Original message:On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn <mike at plan99.net> wrote:
> Hi,
>
> Some of us have put together an open letter to the Linux packaging
> community, outlining why Bitcoin is different to other programs and asking
> them to not patch or modify the upstream sources.
>
> Please consider signing it if you agree (I think the wording by now is fine,
> so don't edit the contents - use the comment feature if you want to though).
>
> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
>
> The trigger for this is the discovery that Debian bitcoind's got split out
> of the consensus some time in April, for reasons that nobody yet figured out
> but is presumably related to a patch (eg it uses system leveldb).
Hi Mike,
Debian's bitcoin is maintained on an open and archived mailing list
and git repo:
Debian Bitcoin Packaging Team <pkg-bitcoin-devel at lists.alioth.debian.org>
If there is a problem or question, getting an answer should be really
easy. It would be good to include them in the discussion there (I
CC:ed the list). If the upstream developers have a consensus that
distribution packaging is not in the best interest of the project,
then I personally would defer to their judgement and request removal.
I'm leaving this open for other opinions from the Debian side.
That said, let me summarize the arguments and see if we can figure out
a permanent solution:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user and the network.
Response: Is there a way to "certify" the Debian libraries? Debian
bitcoind/bitcoin-qt runs the compile test during all architectures.
MIPS has been failing recently, but no one has looked into it yet.
Perhaps it's not worth developers efforts yet, but at some point the
technology should reach a point it can be redistributed.
2) Bitcoin is new technology, so any patches have the ability of
harming both the network and user.
Response: I, and I'm sure everyone else working on it, totally agrees.
All patches are public [1], you can see that the patches are only to
the build system (except for one adding a debug message). Is there a
specific patch or bug that is problematic? This seems to be
reiterating (1) above: don't patch the build system to use libraries
that were not audited by the developers.
The two solutions are: (1) no one besides the upstream developers
compiles and distributes binaries, ever, or (2) upstream comes up with
a system where someone besides them can compile working binaries for
distribution. Most likely the best solution is to do (1) until
upstream sets up a system to allow (2).
I'm curious as to other's opinions.
Thanks,
Scott
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=tree;f=debian/patches;h=ba576f9f3ddad47a2f85dcbfb7a0b3482834f19f;hb=HEAD