some port was "nice" enough to remove TeX w/o my permission

Ryan Schmidt ryandesign at
Sun Aug 5 01:28:42 PDT 2012

On Aug 4, 2012, at 17:07, Jeremy Lavergne <jeremy at> wrote:

>> I really don't think so… *installing* a port should not *uninstall* any other ports. *Upgrading* a port *could* uninstall old versions of dependencies, *if* you used the "-u" flag when upgrading to indicate that you wanted that to happen.
> For most users, uninstall and deactivate are effectively the same thing. 

Sure, I wasn't trying to make a distinction about that. I was trying to say that installing a port should not uninstall (or deactivate) another port. But below you've found an exception to that:

> With that in mind, I know in some packages are deactivated during an install because a given files may be installed by a different package in separate versions of the package. If you don't remove the other package first, you'll run into an error where a file is already installed by another package.
> This happens in various category:textproc and category:kde4 packages (pdfjam comes to mind as one that "uninstalls" texlive-bin-extra).

Ah yes. pdfjam does use the so-called "deactivate hack", an unusual situation which does leave another port deactivated. As the comment in the port explains:

    # texlive-bin-extra used to contain pdfjam, but doesn't
    # anymore. If the old version is installed, deactivate it to avoid
    # a conflict.

So, if you had an old version of texlive-bin-extra installed (one that provided pdfjam), and then you try to install the standalone pdfjam port, it will deactivate your old texlive-bin-extra for you to avoid a conflict that you would then manually have to resolve. You will also have to upgrade texlive-bin-extra to the newer version that does not provide its own copy of pdfjam anymore. Often, people run "sudo port upgrade outdated", to upgrade all outdated ports at once, which should avoid any problems. 

More information about the macports-users mailing list