How image installs work [was Re: The image question]

Daniel J. Luke dluke at geeklair.net
Fri Mar 9 06:53:56 PST 2007


On Mar 8, 2007, at 11:13 PM, Jordan K. Hubbard wrote:
> On Mar 8, 2007, at 4:21 PM, Yves de Champlain wrote:
>> Of course, I could say that it could also be done with tarballs  
>> instead of hard links and you could say that I really missed the  
>> whole  point.  But anyway, my original question was "can someone  
>> explain ?" rather than "can we dump this crap ?".

[snip]

> Let's also say you have some non-macports aware software which  
> simply links with whichever dylib is in /opt/local/lib and uses  
> it.  With image mode, you could trivially "install" both but only  
> activate one or the other as needed, perhaps flipping back and  
> forth to see which jpeg library was truly the most usable.

This is equally easy with archive mode. If archive mode commands were  
enhanced to let you install/uninstall older archives (along with the  
'current' ones) it would all of the functionality (and a little more)  
than the current image mode code.

> Software, particularly open source software, breaks the API/ABI  
> contract with other software that depends on it all the time.  As  
> long as those deps are hard-wired to the canonical installation  
> location for that software, you don't have a lot of options.  Let's  
> use libjpeg as a (less good) example again.

[snip]

Here's another variant of that:

1 - libfoo.dylib v. 1.0 comes out and it is so good that everyone  
starts writing apps that use it.
2 - a serious security flaw is found in libfoo and is fixed in libfoo  
v. 1.1 with no api/abi changes
3 - oh no, since we're "solving the fragile dependency problem" we  
now need to re-build/re-link every application that depended on  
libfoo since we installed it into a version-dependent directory

Having things directly depend on the versioned-directory port also  
makes the dependency tree more complicated (and less obvious to the  
end-user).

[snip]

> One, software which is actually not affected by the API changes  
> (let's say they didn't change *everything*) has to be modified to  
> use the new libjpeg because you've renamed /opt/local/include/ 
> jpeg.h to something else.  Two, I've now obfuscated the new jpeg  
> whereas the old and now obsolete version is the one with the  
> filenames that "make sense".

Or one could take the opposite approach and obfuscate the old jpeg  
(and let the infrastructure know that it has to re-build all the  
dependents when the new version of the old port is installed) and let  
the new one install unmolested.

There's no really good solution when we run into abi/api changes and  
I'm not convinced that depending on the image directly actually helps  
(but I would like to be wrong :) ).

> And none of that is even the hardest part.  There are tools which  
> CAN'T be versioned the same way dylibs can (say, bison makes an  
> incompatible change or tclsh gets versioned) and there's literally  
> no good way to deal with the scenario above if you run into it  
> across upgrades.   It's not just a matter of crufting things up,  
> it's also running into "you can't get there from here - some of  
> your software has to go!"

Indeed, that's why there's no system today that can have bsd make,  
gnu make, bsd tar, and gnu tar installed at the same time ;-)

> With image mode, all that can change.  You NEVER have port A depend  
> on port B (version n)'s "activated" location, you have it depend  
> directly on the image location (/opt/local/var/db/dports/software/ 
> $portname-B/$portversion-B/...) and things continue to work no  
> matter how many versions of port B you have lying around.  It also  
> decouples the dependency from whatever the user may choose to have  
> activated for their own convenience - the user no longer has to  
> worry about/deal with weird spontaneous breakage just because they  
> wanted to speculatively install something that looked cool.

As a minor note, this would also significantly change the semantics  
of 'deactivate' as you wouldn't /really/ be deactivating a port  
(since it would still exist in its image location and other ports  
that depend on it would still be using it). So the existing user  
community would  need to be educated/notified about the change in  
behavior.

--
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: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20070309/9d16e724/PGP.bin


More information about the macports-users mailing list