Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))

2018-03-12 Thread Yavor Doganov
Paul Wise wrote: > Hmmm, what about something that looks at the headers? This is possible in theory although it looks complex, fragile and insufficient to me. It would help library maintainers to detect API breaks and subsequently ABI breaks (at least one source for them), but I can't see how it

Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))

2018-03-12 Thread Paul Wise
On Mon, Mar 12, 2018 at 4:20 PM, Yavor Doganov wrote: > Because of the dynamic nature of the language this information is not > available at build time. Hmmm, what about something that looks at the headers? -- bye, pabs https://wiki.debian.org/PaulWise

Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))

2018-03-12 Thread Yavor Doganov
Paul Wise wrote: > On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote: > > If -initWithAddressBook:readOnly: is removed in a new version of the > > library, that's an API/ABI break but again, it won't be reflected in > > the symbols table. In a C/C++ library you'll see a symbol > > disappearing

Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))

2018-03-11 Thread Paul Wise
On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote: > If -initWithAddressBook:readOnly: is removed in a new version of the > library, that's an API/ABI break but again, it won't be reflected in > the symbols table. In a C/C++ library you'll see a symbol > disappearing but it won't happen here.

Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))

2018-03-11 Thread Yavor Doganov
Adam Borowski wrote: > On Tue, Mar 06, 2018 at 08:28:17AM +0200, Yavor Doganov wrote: > > * Package name: addresses-for-gnustep > >Version : 0.4.8-3 > I don't understand ObjC library stuff well enough to adequately > check these parts, but it's unlikely we'd get someone else who