On 10/02/2018 05:38 PM, Pavel Hrdina wrote: > On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote: >> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote: >>> Background >>> ========== >> >> [...] >> >>> Two concrete examples are considered here: one is the >>> virConnectNumOfDomains() API which, while known to be racy and having >>> non-racy alternatives, can still be used by developers without >>> getting any kind of warning in the process; the other one is the >>> ability to define a domain without specifying the machine type, which >> >> Okay, but for these particular ones we could do a compile time warning. >> Not that we ever can remove them though. > > Definitely agree with Peter, having a runtime warning for issue that > you cannot change in runtime situation is IMHO wrong. Even though we > cannot remove any API the deprecation warning can be still useful > because it can suggest better API to use instead of the old one. So two of our biggest consumers use python bindings. I'm failing to see how a compile time warning would help here. E.g. if an app is using "conn.conn.numOfDefinedDomains()" we could call virConnectListAllDomains() with appropriate flags. Except we can't, because then the app would be unable to talk to older libvirtds where the procedure doesn't exist. In other words, if our goal is to make users switch to newer versions of functions then we might have to find a better solution (than compilte time warnings). Runtime warnings would work with python though. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
