[Fedora-packaging] one less binary package

Tue May 6 11:48:43 UTC 2014

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