>>>>> "AB" == Andreas Bierfert writes: AB> During the next hours opensync will be downgraded to version 0.22 in rawhide as AB> has been discussed on the devel list recently and been prepared for a while by AB> Adam Williamson and me. AB> Test packages can be found here [1] a bug for the downgrade has been opened AB> here [2]. AB> This downgrade will mean for all packages which depend on opensync in some way AB> to be rebuild. If there are questions let me and Adam know. Is anybody actively working on porting these broken deps in rawhide to the newly downgraded opensync? Broken deps for i386 ---------------------------------------------------------- libopensync-plugin-kdepim-0.36-2.fc11.i586 requires libopensync.so.1 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0 libopensync-plugin-syncml-0.35-4.fc10.i386 requires libopensync.so.1 libopensync-plugin-vformat-0.36-2.fc11.i586 requires libopensync.so.1 One of the continuous problem with pushing out new sonames I've observed, is that once they are done the person doing the breaking tends to forget about the breakage that results if they don't happen to own the broken packages in question. Obviously the active maintainer should fix them if possible, but in some cases the person who is experiencing the breakage may not immediately be aware of what may need fixing or be able to actual implement the fix. In these cases it should be incumbent on the person creating the breakage to assist in all porting and fixing of the package (e.g. provide a guide to porting, open up bugs on the package with patches to spec files etc.). If the primary maintainer cannot or will not fix the package themselves in a timely manner (e.g. in a few days or a week), they should try to rebuild and push the affect package themselves (especially if they are a provenpackager). Otherwise there is a tendency to let the broken packages slide to the point that there is a rush to fix them just before a freeze and that doesn't give rawhide testers enough time to see if the API/soname fixes actually worked in the sense of resulting in functioning software that doesn't fail in weird ways at runtime. Let's try and avoid that in this circumstance. Alex -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
