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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V1m21-0000ZU-AI for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 23:30:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1V1m1y-0001Iv-L3
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 23:30:13 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V1m1r-0001rA-MV for bitcoin-development@lists.sourceforge.net;
Wed, 24 Jul 2013 01:30:03 +0200
Received: from linuxpal.mit.edu ([18.62.1.14])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Jul 2013 01:30:03 +0200
Received: from gdt by linuxpal.mit.edu with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Jul 2013 01:30:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Greg Troxel <gdt@work.lexort.com>
Date: Tue, 23 Jul 2013 19:23:27 -0400
Message-ID: <smumwpcg8sw.fsf@linuxpal.mit.edu>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: linuxpal.mit.edu
OpenPGP: id=098ED60E
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/23.4 (berkeley-unix)
Cancel-Lock: sha1:CGr5oA7LX2U6BbUu2eEcfjxImY0=
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1V1m1y-0001Iv-L3
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:30:13 -0000
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")?
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)?
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. Synchronous updates of
multiple packages is difficult, and runs into A wants only n of C, while
B wants only m. So if you are talking about running regression tests
with the set of versions of a dependency that are considered reasonable,
and there's therefore a solution to the multiple-package constraint
problem, that seems ok.
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.
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.
Greg
|
