[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