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