Control: reassign -1 libgpg-error0 1.15-1 On 2014-10-15 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > On 10/15/2014 05:03 PM, Tim Connors wrote: > > Note that in that thread, "Our users will never see the warning message > > since packages built against the newer gpg-error will depend on it and > > packages built against the old one will not show the warning either. (I > > have not actually run any tests to verify this, but I guess you did.)"
> > We do see the warning message, because the likes of a later version of > > libgcrypt doesn't appear to depend on the required version of > > libgpg-error (it depends on >= 1.10, whereas it appears from that > > discussion to have been built against >=1.15). Hello, Well, what actually happened was: f0f0d949734e4841070bab1971700df1463c3b24 Pre-existing symbols (those that used to be marked @Base) have been brought into the GPG_ERROR_1.0 version node, but i've marked them as present in earlier versions of the package -- tools compiled against newer versions, but which just use these older symbols should be installable with older versions of libgpg-error. i.e. at the time of the respective libgpg-error upload, Daniel thought it was better to not have have a stricter dependency which only avoided a warning message. > hm, i suppose this means that we might want to bump the .symbols file in > libgpg-error0 to refer to 1.15 for all symbols since the version node > was introduced there? > that seems like it would be similar to a library transition, though, and > i know that the release team is frowning on that at this late date, and > it would be entirely for the purpose of avoiding a warning (not an error). > I'm not sure this would be worth the tradeoff, but i'm willing to > consider it if people feel strongly about it. I think it would be a good idea and do not think this is like a library transition at all. libgpg-error is up to date in testing (1.16). - Bumping the version-dependency of the affected symbols to 1.15 in the symbol file will not hurt or delay testing propagation of reverse dependencies. This more like uploading a new upstream versions of shared library (without symbol file) bumping the shlibs. (Which ist still allowed.) Just without the possibly negative effect of delaying other packages. What would make it a little bit like a library transition is if you later asked -release to binnmu all libgpg-error reverse dependencies to make sure they got a strict dependency. I guess they would do it if they had buildd time to spare. But this is a optional second step. If -release does not want to, nothing is lost. Anyway. Daniel, I am reassigning to libgpg-error0, since that is where the fix will need to happen. Please simply send it back if you disagree. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org