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?
Is there anything I can do to have resiprocate-b2bua eliminated from F20 as part of this update?
As far as I know, this B2BUA code is not widely used and it is quite likely nobody has installed the package at all. In 7 years that this code has been in the upstream project, we only had two queries about it on the mailing list.
Regards,
Daniel
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.
-Toshio
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.
-----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.
packaging@lists.fedoraproject.org