Here's some more information (this is similar to the ABI most Linux programs use):
https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf Sent with Proton Mail secure email. On Tuesday, July 21st, 2026 at 12:28, CS Sushi Man <[email protected]> wrote: > I'll be a little pedantic here :>). Technically, an ABI pertains > to the manner in which an assembler program will interact with > itself (Ex. when a program calls an internal function). The ABI > describes how arguments are passed, which registers should be > saved, Etc.. RPM macros are *far* closer to being an API, than an > ABI, as APIs describes the *functions* that a program may use, as > opposed to the interactions between the functions themselves. > > Technically, macros are also different from functions (they may > generate inline code through the compiler, or may refer to > functions that write themselves). I've consulted ChatGPT on what > these APIs may typically be named, and they are typically named > "Macro APIs," or "Macro interfaces" (I'm not sure if these names > are correct). > > https://en.wikipedia.org/wiki/Application_binary_interface > https://en.wikipedia.org/wiki/API > > > Sent with Proton Mail secure email. > > On Tuesday, July 21st, 2026 at 11:50, Neal Gompa <[email protected]> wrote: > > > On Tue, Jul 21, 2026 at 6:20 AM Jakub Jelen <[email protected]> wrote: > > > > > > On Tue, Jul 21, 2026 at 11:01 AM Zbigniew Jędrzejewski-Szmek > > > <[email protected]> wrote: > > >> > > >> On Mon, Jul 20, 2026 at 02:42:38PM -0500, Maxwell G wrote: > > >> > Jul 20, 2026 11:50:33 AM Neal Gompa <[email protected]>: > > >> > > > >> > > Sorry, I don't think this makes sense. Why %openpgpverify instead of > > >> > > just changing the implementation under %gpgverify? > > >> > If we can ensure that changing the implementation doesn't break any > > >> > existing > > >> > packages, I think updating the existing one makes sense, but otherwise > > >> > renaming it is probably better. > > >> > > >> I'm with Neal on this… Please make the existing macro use the new tool. > > > > > > > > > As already mentioned by Fabio, the gpgverify naming is confusing as its > > > tied to the > > > GnuPG name (instead of the OpenPGP standard) and we deliberately wanted > > > to avoid > > > this confusion. > > > > > > > It wouldn't matter in practice, because I think I would say no matter > > what you do, you have to fix %gpgverify too. > > > > With my FESCo hat on, I don't see myself reasonably considering to > > approve this change. The rationale is too weak. If you want to > > introduce an *additional* interface, sure, whatever. But as it stands, > > this juice is not worth the squeeze. > > > > And calling it %openpgpverify is just nonsense. *If* I were to accept > > a rename of the macro, I would *only* reasonably consider %pgpverify, > > since that's the name of the format. > > > > And even beyond that, GPG is deeply embedded as the name in the > > ecosystem. Even if we're not using GnuPG, we're not going to go > > through and do hundreds of API/ABI breaks across the ecosystem just > > for a rename. > > > > Don't make it harder on us unless there's a seriously compelling reason. > > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > -- -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
