From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 23 Jul 2013 23:45:26 +0000
User-Agent: KMail/1.13.7 (Linux/3.7.10-gentoo; KDE/4.10.4; x86_64; ; )
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
	<smumwpcg8sw.fsf@linuxpal.mit.edu>
In-Reply-To: <smumwpcg8sw.fsf@linuxpal.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2520182.IJj2QRvikL";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Content-Transfer-Encoding: 7bit
Message-Id: <201307232345.37289.luke@dashjr.org>
Cc: Greg Troxel <gdt@work.lexort.com>
Subject: Re: [Bitcoin-development] Linux packaging letter
Precedence: list

--nextPart2520182.IJj2QRvikL
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Tuesday, July 23, 2013 11:23:27 PM Greg Troxel wrote:
> I find it interesting that this is a "linux packaging letter".  How much
> of this applies to pkgsrc, FreeBSD ports, OpenBSD ports, and other
> non-Linux packaging systems (pkgsrc supports Linux as on of 20 operating
> systems, but is not a "Linux packaging system")?

It was written with bitcoind/Bitcoin-Qt in mind, which don't work on BSD. :p

> Is the repeatable build infrastructure portable (to any reasonable
> mostly-POSIX-compliant system, with gcc or clang)?  I have the vague
> impression it's Ubuntu only, but I am very unclear on this point.  How
> does this repeatableness interact with building for multiple operating
> systems and cpu types (say 20 OS, with typically 3 versions of the OS
> for each, with 1-20 cpu types per OS, for a cross-product of perhaps 200
> combinations)?

It should be portable to other systems, though hasn't been done yet.
Would be nice if the concepts it uses could be integrated into the package-
building systems.

> Requiring precise library depdendencies is quite awkward.  Certainly
> requiring new enough to avoid known bugs is understandable, but that
> should be caught at configure time and fail.

The problem is that we require bugs. That is, if your library has those bug=
s=20
fixed, you have introduced a security vulnerability.

> It seems like a bug that the package will build on BE systems and then
> fail tests.   If it's known not to be ok, it seems that absent some
> configure-time flag the build should fail.

There is no configure-time for this node software yet. The autoconf-based o=
ne=20
in the works *does* make this check, however.

> Asking people not to patch should mean willingnesss to make accomodation
> in the master sources for build issues for multiple packaging systems.
> I haven't gotten around to packaging this for pkgsrc - so far I only
> have the energy to lurk (due to too many things on the todo list).  But
> I often find that some changes are needed.  If you're willing (in
> theory) to add in configure flags to control build behavior (in a way
> that you can audit and decide is safe), that's great, and of course we
> can discuss an actual situation when one gets figured out.

The review process is very slow and strict, but that is because of the same=
=20
reasons it isn't safe to distribute patched versions in general. Merging yo=
ur=20
patches to mainline is not only a good idea, but it helps to ensure they ge=
t=20
the necessary testing needed to be safe.

Luke

--nextPart2520182.IJj2QRvikL
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQQcBAABCAAGBQJR7xWgAAoJEL0ClCQh9Iify+wf/i2jZLpIx4oojvnp90mOJ4Vx
zRphCrt4jFnLnY1w+BBSMlWx9YUG6IKRwVtG97ex4hMNMvtDSCfIO7eGpIWQHvhF
aWWqPHBYa9QIzvLaRDnquVsrSnoxnf4bHCwuBhLreqTQSCwPvuWYtmN/naCB/LDg
pKF86+HuPH3XLrnuG2Q+vCDC73EBEqbMIYnUWTE4zJpV0zEtWFMqn9pVtZZUEBRu
bGGdQ1NwvHj7FfMqOqsZX8oTzT6U9jFQZmg6J29qPD7gJ5ptb3VVhV2k/CNkteaz
cna85apfwelr33bxQrrcToHb1XWtMsL4lkqLaj4eGUr4nctXiFJnyk4seumaNzq6
b38RrhuaHYqvv7t0xg0cy9iQ6L65oHI6ZLg86y7hkAaNjc5Il+pfhKr9OPP5veRg
VTvGaDzp9gVNblLI2EKa3HBRP8OMu4Vzh/I3XnWB4Ywi5Nk3QeJGjy3QScvi6QJN
K36NWEOFfiapTdQu0WZcgiuom5tuRPogCBAZD3CbvswGJHPaI5qCgga3AACJzlda
0jc6s+LHM3XkkxJyfb3Lv8+Fu40vxGA8rF9ohM5J6q+Y4fsh8DOyHr3OnrqtympP
Jy39LhUHbifi4HcEF41bKU61iXhSfPhoXv1U5J+8VUrTRuddVqj1kHrw+rEYaSt6
icbQHsYWQlzJAbMn0xQQR/j2o+MwL0fXjTOEnDC0TkRj0O+0Mg6ATX75hCJly/ih
2Tm18+Dl7K3gwOUBa0MDVxstsrwkwMadVSj/6pElbcI0W/pJuZLjQuzsUrbFoq8b
gLUFLvxUluYfaEeEuIYMDkho/sufOAX5e9X+Y0AwICpN0BXaBKxd0zwpYDP90wqC
pVa8OwX8jI9JQigq1VCGmtfs8uRraz3LpRo1C8179h5bM6O7AMhYV/VYYZ7D6vfd
OrQPmdklTv1GELX0eNNOlO5PNNS9UPWoMCCNBpUVy178U+e4Mk4hUJerH7O4R0kb
YOIE+F5DRhz5pr5P0suSTNPy+CYcmAIE2ooAsPDqBibzKgZgAVUQ+siUBwrDfyDW
Ng1hPpJjPvM1QpNTTYBJdhDbPRV7co72RJlwVPjg6CZqALIyVJqq9perY0GvPFE2
6bs2cE3xm2mI5v+zSN5IWuOQ0R6Xko5Ifj8m0roFKEJNcN2AQqRGVo2PGol7GinD
8Oq6cmGMEpFIDZNDBD1GL8P5WzpFz8nmQWFKPWoiZ3KCjRShdQgvKTnH3H709Du2
RAK/aakPLZWbRGNuQJjHCona+SzIi/4y1tLx4v/LfKNpXjEoApqOB5SQJclLSW/I
LxrfxQM74vJ2hpMGCJ0Yb4224arNp0lJdByrfwf9yzhHG5jcmoKdmc3Ri8z1YZI=
=Bnfm
-----END PGP SIGNATURE-----

--nextPart2520182.IJj2QRvikL--