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>[EMAIL PROTECTED]
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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
