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:
parent
3667a650fa
commit
71c3c7e4bd
|
@ -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"
|
||||
}
|
||||
]
|
||||
}
|
Loading…
Reference in New Issue