On Thu, Jul 23, 2009 at 01:40:57PM +0200, Ruben de Groot wrote: > > > > > > Erm, doesn't that defeat the whole point of having compat* libraries? > > BTW, why don't you just let the old libraries lie in your system, or use libmap.conf just to map them to the newer ones? As long as there is no ABI breakage this will work. > > The problem is that while a single port directly depending on a compat > > library may work indefinitely this way, you'll have many problems when > > you mix and match ports depending on libraries from other ports, mixing > > ld and new libraries dependancies. > > Can you give a concrete example of this? I've never had any such problems. If port A depends on library from port B which itself depends on library in base system foo.so.1, but program A was recompiled and itself depends on library foo.so.2 ld could have an hard time linking them at runtime I think. Anyway, I think someone with better uderstanding of the internals of ld can give better explanations. Anyway this is academic, for yhow I understand it, symbol versioning will solve this in a not too far future... > > > I never used the compat bits, but I really think they are there for > > software you have just in binary form, and no way to recompile. > > That may be the main reason, but there can be many others. > For example, I'm still using the subversion 1.5 client compiled on 6.x > because the newer version from ports (1.6) doesn't play nice with eclipse > (subclipse). You have the sources, you could anyway recompile an old version. > > > If recompiling all ports is problematic just wait a few days and uupdate > > using packages... > > Updating using packages might not be an option at all. Example: mod_php5 If you manage many servers you should anyway have a machine to make your own packages too and roll those ones out to production machines, I think. -- Guido Falsi <mad_at_madpilot.net>Received on Thu Jul 23 2009 - 10:15:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC