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

[Jordan K. Hubbard]

On Mar 9, 2007, at 6:53 AM, Daniel J. Luke wrote:

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

This is indeed an issue, though you must admit that this could just  
as easily be solved with a little policy.   No incompatible API/ABI  
changes and just a security fix?  Fine, give it a revision number for  
auditing purposes (which will not permute version info) and reinstall  
it in-place.  You could even store the revision number somewhere in  
the image directory so that it was possible to determine that it  
_had_ been updated, but in a fashion that did not require all the  
upstream clients to change anything.

Then the problem becomes no worse than the one we already have for  
security/other updates which bump the version number.  You still have  
to rebuild the clients if you want the benefits of the update.

>> 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 ;-)

I'm sure you meant that in jest, but actually, that assertion is  
completely correct.  In order to install all at the same time, we  
require the user to take the hit of figuring out how to invoke the  
others.  There then becomes the notion of 1st and 2nd class citizens  
- GNU make is first class, since it claims the title "make", and  
bsdmake becomes 2nd class because you have to go out of your way to  
use it (assuming you found it at all).   Changing your mind about  
this as a vendor then becomes more or less impossible as the status  
quo becomes codified.  make == GNU make, period, because it's always  
been that way and the very notion of letting the user select a  
"command profile" was never a part of the bargain.  If you decide to  
make "tar" be BSD tar instead of GNU tar, you also get to field the  
bug reports from users who don't find the two entirely  
interchangeable even though BSD tar has some demonstrated advantages,  
like not requiring the user to know if a tarball is gzip'd or bzip'd  
and pass the appropriate flag (z or j) - it auto-figures that out.   
All casualties of a static namespace.

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

Hmmm?   You're describing deactivate's semantics today - it lives in  
its image location regardless of whether or not it's active.  The  
only thing we're talking about is making the dependencies non-fragile  
in the face of deactivate.

- Jordan