> > Morten> I'm not involved in the packaging of pysnmp, but I guess > > Morten> packaging the 3.x- 4.x-series as separate packages sounds > > Morten> like a good idea if we really want the version 3 and 4 in > > Morten> Debian before upstream freezes their API. > > > > I think so too. I have python-pysnmp4 ready, available on the svn > > repository of debian-python team. I can package pysnmp3 too, but i would > > like to wait for Jan Luebbe answer about these mails ;). > > All versions use the pysnmp package name (and therfore the packages > conflict against each other), so it would impossible to one package with > depends on v2 together with one which depends on v4.
Yup, that's a sort of design flaw. I've underestimated the impact of API changes in this project. :-( As an ugly workaround, one could install pysnmp's into different directories and tackle PYTHONPATH on a per-application basis. > v4 contains a mechanism to select the required version before importing > pysnmp. So it should be possible to port this mechanism to v2 and v3 and > create a pysnmp-common package which contains this module. If anyone wants to backport this code into pysnmp[23], I'd happily commit this into the distros or create a stand-alone package. Otherwise, I can do that by myself. Just let me know. > Of course that would require all users of pysnmp to specifiy the > required version. > > The (imho) cleaner solution would be to use pysnmp[234] as the package > names. This sould be coordinated with upstream. I'm a bit reluctant about this approach because: 1) It would still require a modification to existing packages (rename pysnmp into pysnmp[234]) 2) Looks like pysnmp4 is going to be final in terms of functionality and API (hopefully, oh) so all other versions will be gradually phased out. I'd like the final version to be called just "pysnmp" for the sake of simplicity and aestetics. ;-) -ilya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
