1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1V1mH9-0003ZW-UP
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 23:45:51 +0000
X-ACL-Warn:
Received: from [162.213.26.82] (helo=zinan.dashjr.org)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V1mH8-0007w9-30 for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 23:45:51 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:222:4dff:fe50:4c49])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 03CED27A2966;
Tue, 23 Jul 2013 23:45:40 +0000 (UTC)
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>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.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>
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Headers-End: 1V1mH8-0007w9-30
Cc: Greg Troxel <gdt@work.lexort.com>
Subject: Re: [Bitcoin-development] Linux packaging letter
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2013 23:45:52 -0000
--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--
|
