Daniel Burrows <[EMAIL PROTECTED]> writes: > On Sun, Mar 09, 2008 at 12:52:57PM +0800, Deng Xiyue <[EMAIL PROTECTED]> was > heard to say: >> Daniel Burrows <[EMAIL PROTECTED]> writes: >> > If you want to help out, please do so. The main problem is that I >> > haven't had time to analyze the new release and see what's in it: is it >> > a release for new features, for bugfixes, for internal redesign; is it >> > source-compatible so that it can replace 2.0, or do I need to create a >> > new series of packages; if it's source-compatible, does it need a soname >> > bump; etc. > > I've taken a look at it now. As far as I can tell, basically this is > just a source-incompatible change that introduces new typedefs that will > be used by fairly few programs (mostly those that iterate over signal > binding lists) and drops some old names for things. Why is it so urgent > to upload this new version? Is software using these new features already? > I don't see anything else of note in the NEWS file or in the changelog. > >> The ChangeLog contains various changes happened after 2.0.17, which >> are mainly removal of deprecated compatibility api, many new >> interfaces are added, and several bug fixes. But it seems no ABI >> changes happened, so it should be source compatible (any breakage >> other than deprecated api should be bugs) and there is no shared >> library soversion bump (as it is still unversioned). I suggest an >> upload to experimental ASAP to help testing. If you permit, I'll try >> to do the work and let you review. > > It is not source-compatible. In particular, sigc::slot, a type that > gets used all over if you ever want to store a callback for future use, > is no longer pulled in from slot.h; you need to #include <functors/slot.h> > instead. I haven't yet investigated whether this is the only problem, > but I doubt aptitude is the only program that runs into this. > > I'll upload packages to experimental, but I don't think that charging > ahead with this is a good idea right now. > > Daniel
You are right, my hand-made libsigc++ 2.2.1 is now breaking building of various mm packages I maintain. But I guess such changes are unintentional and should be avoid, so I'm CCing upstream developer for suggestion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
