HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]

[Garrett Cooper]

On Sun, Apr 4, 2010 at 5:11 AM, Rainer Hurling <rhurlin at gwdg.de> wrote:
> On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote:
>>
>> On 3/26/10, Robert Watson<rwatson at freebsd.org>  wrote:
>>>
>>> On Mon, 22 Mar 2010, Xin LI wrote:
>>>
>>>> A MFC of this update is planned, but we will have to make some rather
>>>> aggressive changes against the library and more testing.
>>>>
>>>> Please make sure that you have at least libxml2-2.7.6_2 in your ports
>>>> tree
>>>>
>>>> before even thinking about updating your ports tree.  Older libxml2 uses
>>>> some knowledge of zlib internals that has been changed in this update
>>>> which
>>>> is known to cause problem.
>>>
>>> While the update sounds like a good idea (as does moving to symbol
>>> verisoning
>>> for this library), I'm not yet convinced an MFC is a good idea given the
>>> compatibility issues you describe.  Perhaps you could clarify a bit the
>>> failure mode: this affects only people who rebuild their ports using
>>> exactly
>>> the same ports versions, but after having done an upgrade that includes
>>> this
>>> update?  It sounds like existing binaries will continue to work since
>>> they
>>> will reference the old library version?
>>
>> Yes, but the number of libraries which need to be fixed is a pain. If
>> you go the conservative (not ultra conservative) route, you'll have to
>> rebuild all dependencies of graphics/png and graphics/tiff (which
>> includes a ton of gnome apps, X, etc). Oh, and did I forget to mention
>> that libtool hardcodes paths and versioning information? Of course
>> most people won't see this fact until they run make delete-old-libs,
>> but it's a doosy... This is the primary reason why Gentoo Linux has a
>> script to clean up these [libtool] messes...
>
> To avoid the biggest trouble when updating I temporarily went another way.
> Before 'make delete-old-libs' I made a copy of libz.so.5 under compat:
>
> cp -p /lib/libz.so.5 /usr/local/lib/compat/
> cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/
>
> I plan to delete these copies in some weeks. Do you think this is ok or do I
> have to expect unwanted side effects?

    I'm pretty sure that works as well (just make sure to rerun
ldconfig and ldconfig -32 after the fact -- or do /etc/rc.d/ldconfig
restart, boot your system into multiuser mode, etc, and you should be
in good shape); it should get you past this transition.

    It would be nice if there an entry in UPDATING added for this to
warn people of the breakage and this potential suggested workaround
*HINT*...

>> That point alone is a reason for being ultra-conservative with this
>> MFCing change. This won't affect folks building from scratch after
>> this commit, but it'll easily kill off an afternoon or day for folks
>> upgrading if they one isn't careful because the impact is large.
>>
>> Of course scripting the activity to avoid these times of base system
>> library bumps is trivial, but my script that I whipped up still has
>> rough edges and I'd rather not submit it quite yet...

Thanks,
-Garrett