[MacPorts] #49752: root5: runs "port select root ..." on behalf of user, causing unregistered files to be left on the user's system

[MacPorts]

#49752: root5: runs "port select root ..." on behalf of user, causing unregistered
files to be left on the user's system
---------------------------+----------------------
  Reporter:  ryandesign@…  |      Owner:  jonesc@…
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.3.4
Resolution:                |   Keywords:
      Port:  root5         |
---------------------------+----------------------

Comment (by ryandesign@…):

 Replying to [comment:3 jonesc@…]:
 > The unregistered files are not caused by this, but a flaw in the 'port
 select' mechanism that does not remove them when the user uninstalls the
 root port they point at.

 Right, #47755.

 > I don't see this have anything to do with the root ports themselves.

 It has to do with the root ports because I know of no other ports using
 the select mechanism in this manner, so it may surprise the user, and it
 contradicts the information we usually give to users, which is that the
 user shall run "port select" to select the version they want and that
 MacPorts will not do that for them. If we want this behavior to be
 considered normal, it should be discussed on the macports-dev mailing list
 and the select 1.0 portgroup should be enhanced to offer this feature
 somehow.

 Replying to [comment:5 mojca@…]:
 > If it is absolutely forbidden for a port to run `port select`, we could
 create a port `root +root5/+root6` which creates those symlinks.

 No, we don't want that. If you're thinking of this as analogous to the
 perl5 port, the perl5 port is a bug, not a feature; it only exists because
 the select feature did not exist at the time.

 Replying to [comment:7 mojca@…]:
 > Is running this command automatically causing any (problematic)
 leftovers on the buildbots (that is, until #47755 gets fixed)?

 The files do remain on the buildbot builders, yes, and that is how I
 noticed the problem, because I am currently trying to clean up one of the
 builders and am periodically checking /opt/local/bin to see if it "looks
 clean" to me, and the presence of broken symlinks pointing to root files
 does not "look clean", but now that I know why they're there and that it's
 not because of a problem on this builder but a problem in the port and a
 bug in MacPorts base, I am ignoring them.

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