[MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

MacPorts noreply at macports.org
Wed Jun 3 10:52:03 PDT 2015


#47755: Broken symlink left by select code when selected port is deactivated causes
poppler and other ports using aclocal to fail during configuration.
-----------------------+--------------------------------
  Reporter:  lukasz@…  |      Owner:  macports-tickets@…
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  base      |    Version:  2.3.3
Resolution:            |   Keywords:
      Port:            |
-----------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:14 mojca@…]:
 > Replying to [comment:12 ryandesign@…]:
 > > At this point we consider it a user error to deactivate or uninstall a
 port that you have selected with "port select".
 >
 > This is like saying that deactivating a dependency of another port is
 considered a user error. What if users simply forget that they ever
 selected that port?

 All I was trying to say is that there is nothing unusually broken about
 the user's system; it's simply that the user deactivated a port that had
 been selected. MacPorts should be improved to do something different if
 you attempt to deactivate a selected port. Same thing if you attempt to
 deactivate a loaded port, which currently also proceeds without complaint,
 with possibly unexpected results.

 > I would say that deactivation/uninstallation should also
 (automatically?) remove symlinks to `foo-bar`, but I'm not sure what the
 behaviour should be in this particular scenario:
 > {{{
 > port select foo foo-bar
 > port deactivate foo-bar
 > port activate foo-bar
 > }}}
 > Should `foo` still point to `foo-bar` or not?

 Simplest would be to delegate the responsibility to the user by preventing
 deactivation, unless forced.

 > > Perhaps MacPorts base should be modified to prevent you from
 deactivating or uninstalling a port that you've selected.
 >
 > This could be another solution. (But `-f` would probably override that?
 Would upgrading the port still work as expected?)

 Sure, allowing it to be forced seems to be in line with the idea that
 forcing should only be done by those who understand the consequences. It
 would be easier for users to understand the consequences if we explained
 them better in the error messages.

 Agreed, attention needs to be paid to ensure that upgrade still work
 without complaint, and also in the case of auto-loaded ports (like
 certsync). In the case of manually-loaded ports (all the rest of the ports
 that use the startupitem keywords), something also needs to be done.
 Otherwise we have users who, say, upgrade mysql56, but the old version is
 still loaded and running. We should at least print a message reminding the
 user to reload the port at some point. Not sure we should necessarily do
 it for the user, since they may want more control over when it happens.

-- 
Ticket URL: <https://trac.macports.org/ticket/47755#comment:15>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list