On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote:
On 3/26/10, Robert Watson<rwat...@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...
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
