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

[Greg Shenaut]

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

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.

Greg Shenaut