Control: severity -1 normal Control: tags -1 = upstream On Sat, Apr 21, 2018 at 08:36:58AM +0200, Michael Biebl wrote: > Afaiu, the idea behind this wrapper is, that it's up to the actual > application to decide which implementation it wants, i.e. glib > (python-gobject-2) or the gi based Glib (python3-gi + gir1.2-glib-2.0) , > and the application should declare the proper dependency.
Since this is a concious upstream choice, I am lowering severity. It still seems like a bad idea to me, because the behaviour of the module depends on what happens to be installed. If the choice is up to the developer, a developer should be able to encode her choice into the source. I see tow major techniques to avoid this issue: * Having two (sub)modules for each way of integration. * Having some kind of setup/install function that takes care of setting up the integration. (See e.g. apt_pkg.init() or gbulb.install()) Implementing either of these would be considered an API break, so fixing this certainly requires upstream involvement. > If I add a dependency to python3-slip-dbus (assuming that would be the > correct package and not python3-slip), I wouldn't know if I should add > python-gobject-2 > or > python3-gi, gir1.2-glib-2.0 > Both feels wrong somehow. You could use a dependency alternative. Of course that also means encoding a default choice, but a user would always get a working package. I do wonder though why you list python-gobject-2 here as it is a Python 2 module. That doesn't seem to fit into the picture of a python3 package at all and there is no python-slip-dbus that could be relevant. Helmut
