How image installs work [was Re: The image question]
gkshenaut at ucdavis.edu
Mon Mar 12 14:32:16 PDT 2007
On Mar 12, 2007, at 2:08 PM, Jay Sachs wrote:
> On Mar 12, 2007, at 4:47 PM, Ryan Schmidt wrote:
>> On Mar 10, 2007, at 10:11, Daniel J. Luke wrote:
>>> The image mode solution Jordan is proposing would let you upgrade
>>> libiconv without breaking anything, but you really wouldn't be
>>> upgrading libiconv (as everything you previously built against it
>>> would still be using the old version).
>> Seems to me that it would be ideal if I could have version A of a
>> library installed, then install a whole bunch of software that
>> depends on that library. Then install a new version B of the
>> library which breaks backward compatibility. Keep both versions of
>> the library installed at the same time. Attempting to uninstall
>> version A would show you which other packages still depend on
>> version A of the library, so that you can rebuild those packages
>> against version B. Once you've done all that, version A can be
> It seems that image mode doesn't preclude this. One could imagine
> operations like
> port upgrade-depending-ports <dependency-name>[@version]
> which upgrades all packages depending on dependency-name to the
> latest (or specified even) version,
> port delete-unused-inactive-images [name ...]
> which removes the images of all unreferenced inactive packages.
> Note I'm saying "imagine" operations. Not being a macports
> developer, I can't comment on the feasibility of implementing those
Since I'm not a macports developer either, and since we are imagining
how to deal with obsolescence within the ports tree, I suggest as an
analogy the way that inode table links are implemented in the
traditional UNIX filesystem.
That is, a package that is installed always has a link to it, just as
inodes that have directory entries pointing to them have their link
count increment for each entry. A package that is not installed, but
that an installed package points to, also would have its link count
increment to reflect that, similar to how each time an inode is
opened the system increments its link count.
When some package X is uninstalled (or replaced by a newer version),
then its link count and the link count of all packages it references
are decremented by one. But if some other package that references X
is still installed, then X would continue to have a nonzero link
count and therefore not be removed. Only when all packages that refer
to X have been removed or replaced, and its link count goes down to
zero, would the now obsolete and useless package finally get deleted.
In effect, any time that a package is deleted or updated, a kind of
garbage collection would go through all referenced links,
incrementing or decrementing link counts, and removing branches where
the link count reaches zero.
This would have to mean that nothing would ever really be deleted in
the underlying macports tree until nothing, anywhere in the tree
refers to it (including older, but still used, versions of packages).
However, in individual end-user systems, packages could be removed
once nothing refers to them locally.
I do see one problem with this: if I write a program that depends on
a certain version of package X, but that isn't part of macports
itself, then I need some way to tell macports to count that program
as a reference to package X.
More information about the macports-users