-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/06/2014 02:57 AM, Daniel Pocock wrote: > On 05/05/14 22:14, Toshio Kuratomi wrote: >> On Mon, May 05, 2014 at 09:54:10PM +0200, Daniel Pocock wrote: >>> >>> >>> Hi all, >>> >>> My resiprocate package produces multiple binary packages >>> >>> As of v1.9.x, one of the binary packages doesn't exist any >>> more. It is called resiprocate-b2bua >>> >>> Is it OK for me to release v1.9 (without the obsolete package) >>> to F20? >>> >> Strictly speaking I'd say no. But you can make the case to FESCo >> [Fedora Engineering Steering Committee] (note -- this list is >> where the FPC [Fedora Packaging Committee] hangs out. FESCo >> should be reading devel list and if you're asking them a question >> formally, you should use their trac instance: >> https://fedorahosted.org/fesco/) that >> >> Removing the package without a replacement breaks implicit "API" >> and so it contravenes the update policy. Do make the case to >> fesco, though. If the package isn't used much then there is a >> reasonable likelihood that fesco would make an exception for it. >> >> (Note that getting rid of the subpackage in F21+ is okay, though >> -- and feel free to use the Obsoletes mentioned later to remove >> the package on systems where the user has upgraded.) >> >>> Is there anything I can do to have resiprocate-b2bua eliminated >>> from F20 as part of this update? >>> >> You'd probably want to add an Obsolete of the subpackage in the >> main package: >> >> Obsoletes: resiprocate-b2bua >> >> That will get rid of the package on user's systems when the main >> package is updated. Be careful, though, ince you have no >> replacement, this will remove it from systems where users may >> actually be using it. If the user reinstalls the old subpackage >> manually the main package with the Obsoletes will re-remove the >> old subpackage again. If the old version of resiprocate-b2bua >> will not work with the new main package (say because there's a >> shared library in the main package that has updated SONAME) then >> you probably want this behaviour anyway. If the two versions >> could work together, then the Obsoletes (in F20) is something you >> could discuss with FESCo as a way to mitigate the change for >> current users. > > > Thanks for this feedback > > The main package does provide a shared library used by the > subpackage > > The SONAME does include the major.minor version numbers on all the > platforms (Fedora, Debian, ...): > > $ objdump -p /usr/lib/x86_64-linux-gnu/libresip-1.9.so | grep > SONAME SONAME libresip-1.9.so > > This is mainly because SIP is constantly evolving and the API can > change from time to time. > > In theory, this means the old and new versions could be installed > concurrently - does rpm support that though? > > It is quite possible that nobody uses this subpackage whereas there > is significant demand for the WebRTC features in the new version. You could do this, yes. We did that for the libtalloc package for a while in RHEL 5 when we needed to support both the version that had shipped in the release and a new version with features for Samba and SSSD. You can have your SRPM produce a compat-libresip18 package that would provide the older shared object. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNozBoACgkQeiVVYja6o6MUJQCfaX30ERmZ/9zCMV3dbJKJn5Pu yV8An2wecJyPEGZx/M8bnAc9tgieR3kX =ZybF -----END PGP SIGNATURE----- -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
