📅 Original date posted:2013-07-23
📝 Original message: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 bugs
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 one
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
reasons it isn't safe to distribute patched versions in general. Merging your
patches to mainline is not only a good idea, but it helps to ensure they get
the necessary testing needed to be safe.
Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1530 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/9a0e804f/attachment.sig>;
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 15:05:09
in reply to nevent1q…dtjy
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:05:09Event JSON
{
"id": "442712c35e67fc85d4461cc606f2500a2897cd57a0d63dbcef28529e082ddb3a",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686150309,
"kind": 1,
"tags": [
[
"e",
"02fd0cb2c5efae90b48da3cd958f29d02ad6c1875057a9aab52fcb5414be5b89",
"",
"root"
],
[
"e",
"797c0cf5167241fd628e8286b5bdaf6dbfe51ca92b1318547d7fd58491f7a48c",
"",
"reply"
],
[
"p",
"a42a66fde18cffb12a1f47331fae9e1e774bbdda59ff11a9bb70cd8a8a0aeb61"
]
],
"content": "📅 Original date posted:2013-07-23\n📝 Original message:On Tuesday, July 23, 2013 11:23:27 PM Greg Troxel wrote:\n\u003e I find it interesting that this is a \"linux packaging letter\". How much\n\u003e of this applies to pkgsrc, FreeBSD ports, OpenBSD ports, and other\n\u003e non-Linux packaging systems (pkgsrc supports Linux as on of 20 operating\n\u003e systems, but is not a \"Linux packaging system\")?\n\nIt was written with bitcoind/Bitcoin-Qt in mind, which don't work on BSD. :p\n\n\u003e Is the repeatable build infrastructure portable (to any reasonable\n\u003e mostly-POSIX-compliant system, with gcc or clang)? I have the vague\n\u003e impression it's Ubuntu only, but I am very unclear on this point. How\n\u003e does this repeatableness interact with building for multiple operating\n\u003e systems and cpu types (say 20 OS, with typically 3 versions of the OS\n\u003e for each, with 1-20 cpu types per OS, for a cross-product of perhaps 200\n\u003e combinations)?\n\nIt should be portable to other systems, though hasn't been done yet.\nWould be nice if the concepts it uses could be integrated into the package-\nbuilding systems.\n\n\u003e Requiring precise library depdendencies is quite awkward. Certainly\n\u003e requiring new enough to avoid known bugs is understandable, but that\n\u003e should be caught at configure time and fail.\n\nThe problem is that we require bugs. That is, if your library has those bugs \nfixed, you have introduced a security vulnerability.\n\n\u003e It seems like a bug that the package will build on BE systems and then\n\u003e fail tests. If it's known not to be ok, it seems that absent some\n\u003e configure-time flag the build should fail.\n\nThere is no configure-time for this node software yet. The autoconf-based one \nin the works *does* make this check, however.\n\n\u003e Asking people not to patch should mean willingnesss to make accomodation\n\u003e in the master sources for build issues for multiple packaging systems.\n\u003e I haven't gotten around to packaging this for pkgsrc - so far I only\n\u003e have the energy to lurk (due to too many things on the todo list). But\n\u003e I often find that some changes are needed. If you're willing (in\n\u003e theory) to add in configure flags to control build behavior (in a way\n\u003e that you can audit and decide is safe), that's great, and of course we\n\u003e can discuss an actual situation when one gets figured out.\n\nThe review process is very slow and strict, but that is because of the same \nreasons it isn't safe to distribute patched versions in general. Merging your \npatches to mainline is not only a good idea, but it helps to ensure they get \nthe necessary testing needed to be safe.\n\nLuke\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 1530 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/9a0e804f/attachment.sig\u003e",
"sig": "37dc4fe7365bc3e60d694c72389f3091e018aa80e25bd7b966c2115f4ce8626e27123aa857d733047de7572c49bcae2b6ea98f9f54be6f8f527a78bafa629126"
}