How image installs work [was Re: The image question]
Daniel J. Luke
dluke at geeklair.net
Sat Mar 10 08:03:23 PST 2007
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
> 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
>> 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
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
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...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20070310/92c2d99f/PGP.bin
More information about the macports-users