Hi, > > > > I didn't quite understand what is the benefit with a symbols file that > > > > is all wildcards. The package might as well not have any symbols file > > > > as far as I see if it is totally void of actual symbol names. .. > Here is a snippet of the symbol file that you posted in your > original message: > > libcrypto.so.3 libssl3t64 #MINVER# > * Build-Depends-Package: libssl-dev > *@OPENSSL_3.0.0 3.0.0 > *@OPENSSL_3.0.3 3.0.3 > > This is not "only wildcards": It assigns all symbols from the > OPENSSL_3.0.0 symver to libssl-dev 3.0.0, all symbols from > the OPENSSL_3.0.3 symver get assigned to libssl-dev 3.0.3. And so > on. > > I'm not sure if it is even possible to produce a symbols file that > is "only wildcards" (*@*?) - but in any case that can be had by not > having a symbols file.
I don't mean `(*@*?)` but specifically what was in the example, which is as I wrote "totally void of actual symbol names", referring to the first column in the file before the @ part. Maybe I was misusing the term 'symbol name'? By a symbol name I mean the tha callable thing in the ABI, e.g. `OPENSSL_init_ssl`. As I now started doubting my sanity with this, I tested renaming OPENSSL_init_ssl to OPENSSL_init_tls, which would be a major ABI change (and plausible for this project considering e.g. https://github.com/openssl/openssl/issues/3818). The dpkg-gensymbols won't notice anything as the file does not have this, nor any other symbol name, as that part is just all wildcards. The build will pass, but every package using this ABI would likely stop working. Also if removing OPENSSL_init_ssl, or changing OPENSSL_init_ssl from 3_0_0 to 3_5_0, dpkg-gensymbols would not warn or error anything, as all of that continues to match the very lax symbols file. If there is no .symbols file at all, dpkg-gensymbols won't understand that upstream 3_0_0 maps to Debian string 3.0.0 and library dependencies would always point to latest OpenSSL version, but builds still pass without error/warning. The only thing that is caught and can be prevented is if a symbol starts to use a version number not yet in that file. > I hope this clarifies some misunderstandings. Thanks for follow-up. It would make sense if some of the symbol names were grouped with wildcards (e.g. X509_ACERT_*@OPENSSL_3.4.0) to make the list a bit shorter (see how long it is now in https://salsa.debian.org/otto/openssl/-/commit/1403b82459516de60532fe629ea72bf9105157ea). Or if the file started with ` *@OPENSSL_3.0.0 3.0.0` with assumption that all old symbols are fine and we ignore tracking them in detail, but then the symbols introduced in later versions would be itemized. But this current file is just truncated to accept all symbol names, which still does not make sense to me. Apparently you mean that just having the upstream symbol version mapped to a Debian version by the maintainer by repeating the same line over and over so Depends can point to older versions is enough, and there is no need to care about actual symbol names.
