Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V1kfE-0005P5-7W for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 22:02:36 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.41 as permitted sender) client-ip=209.85.160.41; envelope-from=showard314@gmail.com; helo=mail-pb0-f41.google.com; Received: from mail-pb0-f41.google.com ([209.85.160.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V1kfC-00048r-Gm for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 22:02:36 +0000 Received: by mail-pb0-f41.google.com with SMTP id rp16so9029623pbb.28 for ; Tue, 23 Jul 2013 15:02:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.194.13 with SMTP id hs13mr7202797pac.163.1374616948624; Tue, 23 Jul 2013 15:02:28 -0700 (PDT) Received: by 10.70.15.66 with HTTP; Tue, 23 Jul 2013 15:02:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jul 2013 18:02:28 -0400 Message-ID: From: Scott Howard To: Debian Bitcoin Packaging Team Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (showard314[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (showard314[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V1kfC-00048r-Gm Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Linux packaging letter X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:02:36 -0000 On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn 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 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