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

[Daniel J. Luke]

On Mar 9, 2007, at 4:17 PM, Jordan K. Hubbard wrote:
> 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.

That only works if the update is issued as a patch or a release that  
doesn't change the upstream version number (or if we decide to start  
backporting security fixes, or if we start fudging the version  
number, or if we start numbering API/ABI changes and use that for our  
unique tuple).

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

For libraries which only change a minor version number when releasing  
a security update and don't change the API/ABI everything works just  
fine already (because ports tend to link against the compatibility  
symlink).

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

And any other method of choosing between the two will require the  
user to figure out how to invoke the others as well (it'll just be a  
different way of choosing).

> All casualties of a static namespace.

images doesn't make the namespace dynamic, it just standardizes the  
differentiator into a long/obscure path.

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

Today when you deactivate a port, it's deactivated (ie, nothing uses  
it - nothing is linked directly against it, it's not in anyone's  
PATH, etc.).

Under your new semantics, a deactivated port may be required by other  
active ports and so is in some senses still 'active' (while still not  
having the 'active' badge in the registry).

--
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/20070310/92c2d99f/PGP.bin