Re: opensync downgrade to 0.22

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux