On 2/9/26 17:04, Adrian Bunk wrote:
On Mon, Feb 09, 2026 at 04:35:28PM +0300, Michael Tokarev wrote:... 2. The fixes in there introduce two new symbols in shared libraries which appeared in much later versions of the library - 3.20 or 3.21. These new symbols are used internally by freerdp binaries, no existing-in-trixie clients, obviously, don't use these. I can't just add these symbols to the trixie shared libs with min version being current trixie one, because there's a version gap when this symbol doesn't exist.So I use a trick by providing a virtual package with these symbols for trixie, and use alternative dependency - either this virtual package or recent-enough library where this symbol actually appeared. ...New symbols are more common in pu updates than you might imagine, including in core packages like python3. Just using 3.15.0+dfsg-2+deb13u1~ as symbol version for the new symbols would be the normal solution. The version gap does technically exist, but only when upgrading to older versions from testing/unstable AND having a (local) package that is using the symbol installed - this is a pretty theoretical issue. I am not a member of the release team and I am not saying that what you are doing is wrong, but it is not really necessary or usually done.
Adding to that. I spotted error in the versioning there -- https://salsa.debian.org/debian-remote-team/freerdp3/-/commit/070825727652dffdee4a77316d010efdb05ab745 mixes 3.22 vs 3.21. And, since nothing complains, I started looking more closely, and realized these symbols are only used inside the library (libfreerdp3-3 in this case) - it isn't used even in other binaries of the same package. Just inside the library which provides these symbols. So yes, it might be unnecessary in this case. And yes, I fixed the error in there, still providing the virtual package. I can drop this one as an unnecessary complication. I haven't faced such situation before, so thought I'd be cautious. Thanks, /mjt
