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

[Rainer Hurling]

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?

Thanks,
Rainer Hurling


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