svn commit: r422826 - head/security/libsodium

[Mathieu Arnold]

Le 28/09/2016 à 00:03, John Marino a écrit :
> On 9/27/2016 16:58, Mathieu Arnold wrote:
>> Le 27/09/2016 à 23:50, John Marino a écrit :
>>> On 9/27/2016 16:14, Mathieu Arnold wrote:
>>>> Le 27/09/2016 à 21:51, John Marino a écrit :
>>>>> On 9/27/2016 14:43, Vsevolod Stakhov wrote:
>>>>>> Author: vsevolod Date: Tue Sep 27 19:43:32 2016 New Revision:
>>>>>> 422826 URL:
>>>>>> https://svnweb.freebsd.org/changeset/ports/422826
>>>>>>
>>>>>> Log: - Update to 1.0.11
>>>>>>
>>>>>> No bump for dependent port is required as this version has no
>>>>>> API changes
>>>>>>
>>>>>>
>>>>>> Modified: head/security/libsodium/pkg-plist
>>>>>> ==============================================================================
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> --- head/security/libsodium/pkg-plist    Tue Sep 27 18:25:34 2016
>>>>>> (r422825) +++ head/security/libsodium/pkg-plist    Tue Sep 27
>>>>>> 19:43:32 2016 (r422826) @@ -58,7 +58,7 @@
>>>>>> include/sodium/version.h lib/libsodium.a lib/libsodium.so
>>>>>> lib/libsodium.so.18 -lib/libsodium.so.18.1.0
>>>>>> +lib/libsodium.so.18.1.1 libdata/pkgconfig/libsodium.pc
>>>>>> %%PORTDOCS%%%%DOCSDIR%%/AUTHORS
>>>>>> %%PORTDOCS%%%%DOCSDIR%%/README.markdown
>>>>>>
>>>>>
>>>>> First, I don't think the "no API change" means a bump is not
>>>>> mandatory. Secondly, the SO name of the library changed!!!  You
>>>>> have to bump it, there's no question here.
>>>>>
>>>>> It's 1000x better to bump unnecessarily than to skip a bump
>>>>> that is required.
>>>>
>>>> No it did not.
>>>>
>>>> $ readelf -d `make -V STAGEDIR`/usr/local/lib/libsodium.so|grep
>>>> soname 0x000000000000000e SONAME               Library soname:
>>>> [libsodium.so.18]
>>>>
>>>> The file name changed, but software will try to find
>>>> libsodium.so.18, and that will still work.
>>>>
>>>
>>> regardless, why should the bump be avoided? There could have been
>>> fixes against the existing functions.
>>>
>>> I'm starting to see a lot of people go out of their way to bump and
>>> I don't know where the trend is coming from.
>>>
>>> Is portmgr saying vsevolod is correct not to bump this?  I would
>>> bump it and if that's wrong maybe my bump criteria is wrong.
>>
>> You have to bump ports that depend on a .so when the soname changes.
>> For example, if the libsodium update had done this:
>>
>> lib/libsodium.so -lib/libsodium.so.18 -lib/libsodium.so.18.1.0
>> +lib/libsodium.so.19 +lib/libsodium.so.19.2.1
>>
>> You would have needed to bump, because the soname would have changed
>> from libsodium.so.18 to libsodium.so.19, and software built with the
>> old version would have tried to load the .18 lib that did not exist
>> any more.
>>
>> As a general rule, when you don't know what to do, don't do what you
>> guessed, ask.  There are people with more knowledge than you, and
>> they can explain you what you are doing wrong.
>
> I wasn't talking about missing linkage.  I dropped that after you said
> the registered SONAME didn't change.
>
> The point I was making is that there could have been bug fixes to
> existing functions.  Those fixes will only accidentally propagate now.
>
> It's doubtful that many people know with 100% certainty that there are
> no fixes that should be propagated.  I certainly wouldn't tie the
> evaluation to the SONAME.
>
> I can say I am surprised that you think I'm wrong to assert this needs
> a bump.  In my case, the worst that can happen are the ports dependent
> get rebuilt.  In the other case, the worst that can happen is that bug
> fixes don't propagate.  I don't think my position is wrong.

How would bug fixes not propagate ?

You know what a .so is, right ?

If something gets fixed in libfoo.so.1.2.3 and it previously was bad in
libfoo.so.1.2.2, then the fixed function gets in libfoo.so.1.2.3, and
everything using it will get the fixed function.



-- 
Mathieu Arnold


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20160928/e215f8a5/attachment.sig>