I also played some time with the idea to separate out the SNMP implementation. I did just that yesterday by creating a package tentatively called gsnmp. The idea here would be that others can reuse the glib-based SNMP library easily. Now, making this split would imply that scli has another dependency. If you think this is a problem, please let me know.
There is another open question: Should the scli stubs also become a reusable separate package? It would make sense if there are people who are interested to develop other applications that make use of the stubs. One could package this as gsnmpietf (stubs for the IETF MIBs), gsnmpnortel, gsnmpcisco, ...
From my point of view (short intro: Michael Goffioul, KDEPrint and
sKli developer), having access to separate libraries to perform all the SNMP dirty work is a plus. Having access to the internal data is much faster and more reliable than parsing the scli standard output (whose format can change from one version to the other). So I'm pretty much in favor of such a development direction. For the dependency problem, you can still package the whole source code into one package, containing the various libraries and the scli executable, and leave the splitting into separate binary packages to the distro packagers. As final note, I'll add that having access to the stubs is (at least for me) as important as for the gsnmp alone. So yes, putting stubs accessible in separate package/libs is pretty useful.
Bye. Michael.