Hi Paul and others, its surely an interesting topic how to avoid binary name changes and its also interesting to discuss ABI changes and workarounds.
However, my point was that I want to know what policy ftpmaster applies to new binary names and to focus on this topic. I really want to know that policy of ftpmaster and I really would like to see that documented and I'm afraid that thread is drifting away from the original topic that I will not get any answer on this. So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm currently observing and I would be really happy if we can document the policy for changed (and new) binary names of existing source packages. To give another example which has nothing todo with ABI changes: Currently I'm afraid of splitting some Arch: all data from some Arch: any package since I'm simply afraid of the changed package sticking long in new queue. I know this is bad - but I consider users waiting for package updates worse. Kind regards Andreas. [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html Am Mon, Jan 24, 2022 at 10:20:48AM +0800 schrieb Paul Wise: > On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote: > > > That only works if there are no other packages depending on those > > shared libraries which are coming from other source packages. > > I don't think that is true, I believe you can put multiple things in > the depends section of an shlibs file and dpkg-shlibdeps will propagate > that to reverse dependencies just fine. From the manual pages it looks > like the same applies to the symbols files. I found on my system that > there are *already* packages that do something similar (see below). > ... -- http://fam-tille.de