Hi ryan (npub124t…2ca5)
« Package Managers à la Carte – A Formal Model of Dependency Resolution »
https://doi.org/10.1145/3828699
Cool, very nice and great paper! Well, to be honest, I’m not able to parse all in this paper; it’ll deserve a huge mug of coffee and some free time ahead. So maybe my question is already answered. 😁
🤔 What I’m missing is the definition of “package” and “version”.
2.1.1 « A package is a unit of software – source code, a compiled binary, or data – […] Packages are identified by a name, which refers to a package across its releases, and a version, distinguishing one release from another. »
The exact same source code – the exact same “name” and “version” – can produce two different compiled binaries depending on the compilation options for instance.
What seems lacking in this “Package Calculus“ is thus a third item defining a "package”: the “build script“, no?
Either it’s included in the “version” but the ordering seems lost, either the “Package Calculus“ would need to be updated, no?
Appendix D “Singular Dependencies” speaks about Nix/Guix. And from my understanding, that’s the point of this approach: define a “package” as a “name”, a “version” (= source code release) and a “build script”, no?
Simon Tournier
npub1ep…2hv3y
2026-09-24 18:03:02 UTC
Author Public Key
npub1epyahyq7kewv4d5g75ju90k24vauuhxw8h4pvay39uptum9uw55sl2hv3yPublished at
2026-09-24 18:03:02 UTCEvent JSON
{
"id": "837e7a56efd9822754ab41c4d936972019b30e34d0976cfe776923582e726cf4",
"pubkey": "c849db901eb65ccab688f525c2becaab3bce5cce3dea1674912f02be6cbc7529",
"created_at": 1790272982,
"kind": 1,
"tags": [
[
"p",
"55560d69e28d71c2717738fee74aa489e05259335423d4d14dbd8d5220363303"
],
[
"proxy",
"https://social.sciences.re/@zimoun/117327330200921801",
"web"
],
[
"proxy",
"https://social.sciences.re/users/zimoun/statuses/117327330200921801",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://social.sciences.re/users/zimoun/statuses/117327330200921801",
"pink.momostr"
],
[
"-"
]
],
"content": "Hi nostr:npub124tq660z34cuyuth8rlwwj4y38s9ykfn2s3af52dhkx4ygpkxvpsg32ca5\n\n« Package Managers à la Carte – A Formal Model of Dependency Resolution »\nhttps://doi.org/10.1145/3828699\n\nCool, very nice and great paper! Well, to be honest, I’m not able to parse all in this paper; it’ll deserve a huge mug of coffee and some free time ahead. So maybe my question is already answered. 😁\n\n🤔 What I’m missing is the definition of “package” and “version”.\n\n2.1.1 « A package is a unit of software – source code, a compiled binary, or data – […] Packages are identified by a name, which refers to a package across its releases, and a version, distinguishing one release from another. »\n\nThe exact same source code – the exact same “name” and “version” – can produce two different compiled binaries depending on the compilation options for instance.\n\nWhat seems lacking in this “Package Calculus“ is thus a third item defining a \"package”: the “build script“, no?\n\nEither it’s included in the “version” but the ordering seems lost, either the “Package Calculus“ would need to be updated, no?\n\nAppendix D “Singular Dependencies” speaks about Nix/Guix. And from my understanding, that’s the point of this approach: define a “package” as a “name”, a “version” (= source code release) and a “build script”, no?",
"sig": "51e1b37bf9381254f08c63b72d8c73052cca5cd5528f0a148b752a02d9eb8d22166101b85cfc60c680e127b13e91a23dd7168154c19d807198741566aff91568"
}