Update patch set 1

Patch Set 1:

(1 comment)

Patch-set: 1
Reviewer: Gerrit User 1000004 <1000004@035e6965-6537-41bd-912c-053f3cf69326>
Attention: {"person_ident":"Gerrit User 1000004 \u003c1000004@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_1000010\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 1000010 \u003c1000010@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_1000010\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 1000074 \u003c1000074@035e6965-6537-41bd-912c-053f3cf69326\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_1000010\u003e replied on the change"}
This commit is contained in:
Gerrit User 1000010 2024-01-08 15:07:20 +00:00 committed by Gerrit Code Review
parent 3667a650fa
commit 71c3c7e4bd
1 changed files with 18 additions and 0 deletions

View File

@ -88,6 +88,24 @@
"parentUuid": "0a225624_9fbf8bad",
"revId": "c4ea374e4af902458f247da2a04c38205d5e1447",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "e23b5f98_c5888ebe",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 1
},
"lineNbr": 0,
"author": {
"id": 1000010
},
"writtenOn": "2024-01-08T15:07:20Z",
"side": 1,
"message": "\u003e * Yes, it\u0027s a public dependency and it\u0027s part of the public API of the library\n\nHow does this contradict what I am saying? I am not saying that `bcmtoolbox` is not a public dependency of `ortp`. I am saying that for libosmo-abis, `bcmtoolbox` is **not a direct** (but indirect or implicit) dependency, pulled by `ortp`. We don\u0027t require `bcmtoolbox` in our `configure.ac` nor in `debian/control`. This is why I don\u0027t think it\u0027s a good idea to use API of `bcmtoolbox`.\n\n\u003e\u003e they may switch to some other library any day.\n\u003e That would break its ABI/API.\n\nThis whole situation with libosmo-abis not building against recent `ortp` indicates that they don\u0027t care that much about breaking API/ABI. They also did modify signatures of existing public functions, and this is why we have quirks like `HAVE_ORTP_LOG_DOMAIN` and `RTP_SIGNAL_PTR_CAST`.\n\nI am inclined to remove this talloc-to-ortp integration completely (even for old ortp versions), as was suggested by Hoernchen in the IRC. It\u0027s questionable whether we really want to use talloc here.",
"parentUuid": "a6c5bf5e_87c60a0b",
"revId": "c4ea374e4af902458f247da2a04c38205d5e1447",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
}
]
}