Google Summer of Code 2009: Mentors needed!

[Daniel J. Luke]

On Mar 11, 2009, at 8:25 PM, Jordan K. Hubbard wrote:
>> or port foo could just statically link to version X of the library  
>> and port blah can statically (or dynamically) link to version Y.  
>> (the build process for port foo could even build the old version X  
>> lib).
>
> That wouldn't work as a general rule, since back when "foo" was  
> created, X would also likely be the "latest and greatest" and, of  
> course, you would want to ship that as a .dylib since shipping it as  
> a static archive would mean that every client embedded a copy of X  
> within itself, leading to bloated memory consumption and no  
> opportunity to ever update X in-place for security reasons, as  
> previously discussed.

Right, so when X is latest and greatest, you don't statically link,  
but when you have to keep around old foo because it won't be updated  
for Y, you can just rebuild foo and statically link foo with the old X.

The problems you mention (bloated memory consumption, and hard to do  
security updates) are also present with the more complex solution of  
having every version available for linking in the depot. At least with  
statically linking the old and unmaintained program, the choice is not  
automatic and the brokenness is contained to that program.

> This is why static archives are generally discouraged on MacOSX -  
> you want the extra level of indirection in fulfilling the API  
> contract.

indeed. In the case where you're installing an old and unmaintained  
library, though, I think it's desirable to limit it to only the old  
and unmaintained application that requires it, instead of having it  
generally available on the system.

>> I don't really want every version of every library on my system  
>> available for things to link to. Even if we somehow only track ABI  
>> changes, I still probably don't want every ABI version around.
>
> Maybe *you* don't, but anyone who needs every library on their  
> system available for other reasons, and does a halfway reasonable  
> job of garbage collection once in awhile, is not going to share that  
> opinion at all.


until they get rooted because one version of the old lib they have  
(and didn't realize things were linked to) had a bug that never got  
fixed in that old version (since it was fixed in a 'supported'  
version, and not the obsolete one that was still around).

If the only benefit is keeping older applications running even when  
newer libs change the ABI or API and the older application can't be  
updated to use the new lib, then I don't see how the extra  
complication of having every version around and available for linking  
is the best solution.

Maybe there's some other problem it solves that I'm not seeing?

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090312/d38744c1/attachment.bin>