root5, root6: runs "port select root ..." on behalf of user, causing unregistered files to be left on the user's system

[ryandesign (Ryan Carsten Schmidt)]

The root5 port leaves unregistered files in the MacPorts prefix of any user who has installed the root5 port.

$ port installed root5
None of the specified ports are installed.
$ port select root
Available versions for root:
	none
$ ls -l /opt/local/bin | grep root5
lrwxr-xr-x    1 root      wheel        35 Nov  5 00:00 g2root -> /opt/local/libexec/root5/bin/g2root
lrwxr-xr-x    1 root      wheel        35 Nov  5 00:00 genmap -> /opt/local/libexec/root5/bin/genmap
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 genreflex -> /opt/local/libexec/root5/bin/genreflex
lrwxr-xr-x    1 root      wheel        47 Nov  5 00:00 genreflex-rootcint -> /opt/local/libexec/root5/bin/genreflex-rootcint
lrwxr-xr-x    1 root      wheel        35 Nov  5 00:00 h2root -> /opt/local/libexec/root5/bin/h2root
lrwxr-xr-x    1 root      wheel        33 Nov  5 00:00 hadd -> /opt/local/libexec/root5/bin/hadd
lrwxr-xr-x    1 root      wheel        43 Nov  5 00:00 hist2workspace -> /opt/local/libexec/root5/bin/hist2workspace
lrwxr-xr-x    1 root      wheel        37 Nov  5 00:00 memprobe -> /opt/local/libexec/root5/bin/memprobe
lrwxr-xr-x    1 root      wheel        32 Nov  5 00:00 pq2 -> /opt/local/libexec/root5/bin/pq2
lrwxr-xr-x    1 root      wheel        47 Nov  5 00:00 prepareHistFactory -> /opt/local/libexec/root5/bin/prepareHistFactory
lrwxr-xr-x    1 root      wheel        35 Nov  5 00:00 proofd -> /opt/local/libexec/root5/bin/proofd
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 proofserv -> /opt/local/libexec/root5/bin/proofserv
lrwxr-xr-x    1 root      wheel        42 Nov  5 00:00 proofserv.exe -> /opt/local/libexec/root5/bin/proofserv.exe
lrwxr-xr-x    1 root      wheel        36 Nov  5 00:00 rlibmap -> /opt/local/libexec/root5/bin/rlibmap
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 rmkdepend -> /opt/local/libexec/root5/bin/rmkdepend
lrwxr-xr-x    1 root      wheel        33 Nov  5 00:00 root -> /opt/local/libexec/root5/bin/root
lrwxr-xr-x    1 root      wheel        40 Nov  5 00:00 root-config -> /opt/local/libexec/root5/bin/root-config
lrwxr-xr-x    1 root      wheel        37 Nov  5 00:00 root.exe -> /opt/local/libexec/root5/bin/root.exe
lrwxr-xr-x    1 root      wheel        37 Nov  5 00:00 rootcint -> /opt/local/libexec/root5/bin/rootcint
lrwxr-xr-x    1 root      wheel        34 Nov  5 00:00 rootd -> /opt/local/libexec/root5/bin/rootd
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 rootn.exe -> /opt/local/libexec/root5/bin/rootn.exe
lrwxr-xr-x    1 root      wheel        34 Nov  5 00:00 roots -> /opt/local/libexec/root5/bin/roots
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 roots.exe -> /opt/local/libexec/root5/bin/roots.exe
lrwxr-xr-x    1 root      wheel        39 Nov  5 00:00 setxrd.csh -> /opt/local/libexec/root5/bin/setxrd.csh
lrwxr-xr-x    1 root      wheel        38 Nov  5 00:00 setxrd.sh -> /opt/local/libexec/root5/bin/setxrd.sh
lrwxr-xr-x    1 root      wheel        36 Nov  5 00:00 ssh2rpd -> /opt/local/libexec/root5/bin/ssh2rpd
lrwxr-xr-x    1 root      wheel        41 Nov  5 00:00 thisroot.csh -> /opt/local/libexec/root5/bin/thisroot.csh
lrwxr-xr-x    1 root      wheel        40 Nov  5 00:00 thisroot.sh -> /opt/local/libexec/root5/bin/thisroot.sh
lrwxr-xr-x    1 root      wheel        36 Nov  5 00:00 xpdtest -> /opt/local/libexec/root5/bin/xpdtest

This appears to be because the port runs "port select" for the user. Ports must not do that. Ports should only advise the user how to use port select.

Then, I would like this fixed so that these unregistered files are removed from the systems of users who did not themselves run "port select root ...". However, I'm not sure how to do that in a way that does not affect users who did run "port select root ...". We may just leave the cleanup to #47755 which calls for MacPorts itself to remove selected files for ports that are no longer installed.

[cjones051073 (Chris Jones)]

The root5 and root6 ports have done this from when root6 was added. The idea is normally a user will only want one installed, so it seems to me reasonable to select it for them. A clear message is printed warning it is happening. Personally, I see nothing wrong with this.

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. I don't see this have anything to do with the root ports themselves.

Chris

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

If it is absolutely forbidden for a port to run port select, we could create a port root +root5/+root6 which creates those symlinks.

[cjones051073 (Chris Jones)]

Sorry, but no. That just a lot of effort to do the same thing via a different command. If it is forbidden, and personnally i don't see the problem, then fine we just remove it, period. Users either then have to use the versioned binaries directly, or run port select themselves. But first i would want to see the reasoned argument why it should be removed.

[mojca (Mojca Miklavec)]

Is running this command automatically causing any (problematic) leftovers on the buildbots (that is, until #47755 gets fixed)?

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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 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 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.

[cjones051073 (Chris Jones)]

Just trying to close some of my tickets...

So, hats the final consensus on this one ? At this point I would be happy to remove the code that automatic 'port selects' if thats what people would generally prefer ?

[pmetzger (Perry E. Metzger)]

Wasn't there another ticket recently where someone said root5 should be deprecated in favor of root6 anyway?

[cjones051073 (Chris Jones)]

Yes, but I have gone back on that idea a bit as it seems macports clang50 has given it a bit more life...

Also, at some point in the future there will be a root7, so even if root5 is retired there will sill be use for a port select mechanism for root.

[pmetzger (Perry E. Metzger)]

cjones051073: I think you will find that it is unlikely you'll get a strong consensus, because as the port maintainer you understand the situation better than other people. As the port maintainer, I'd choose an option among those available based on the discussion, and submit a pull request on GitHub that closes the ticket.

[cjones051073 (Chris Jones)]

The point is from my perspective, the most convenient for users is to leave the root ports as is, so have them run port select. Personally I don't think from the user point of view the situation currently in place is really any different to what happens if a user installs root(5,6), runs port select themselves, then later on uninstalls root and root_select forgetting that they previously ran port select and that they need to undo this first. Files are left behind not associated to any installed port just the same. This is not something special to the root ports, but any port using the select mechanism. I don't really agree that the fact the root ports do this for the user, makes the situation really any different. Its still a flaw in the port select mechanism.

However, the issue for me, and why I would consider removing the automatic setting, is whether this is causing issues on the buildbots, leaving files behind. How much of an issue that is I cannot judge, as I am not familiar with the details on running the buildbots...

[raimue (Rainer Müller)]

There are separate issues here:

• port select leaves files behind
  This is not a issue of root5 or root6, but a separate base issue (do we already have a ticket?). For example, this could be solved by registering the symlinks created by port select to the corresponding *_select port in the registry, so they are not left behind. However, discussion of that should be subject of another ticket.

• root5 and root6 run port select
  If there is a need to have the effect of 'port select' automatically if nothing was selected before, that should be a feature of base (or the select port group?). It should not be implemented in ports separately. In general, I do not think it is a good idea to execute the port command from within the port command. For example, if port select was locking the registry for write access, you could run into a deadlock. This would better be implemented with the mportselect API of macports1.0, but I think this is currently not exposed to the slave Tcl interpreter.
  As we lived with this state for over two years, I am not saying this needs to be removed from root5 and root6 immediately, but there should be a plan to replace this with a better implementation in the future.

A side note for root5 and root6, I noticed the the post-activate phase uses ui_msg, but should be using notes. Notes are repeated for more visibility after all dependencies and requested ports are installed, while the ui_msg is just somewhere in the output.

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue:

• port select leaves files behind
  This is not a issue of root5 or root6, but a separate base issue (do we already have a ticket?)

#43996

[cjones051073 (Chris Jones)]

Ok, thanks. So as there is a ticket for the core issue here, as I see it, I am going to close this one.

[ryandesign (Ryan Carsten Schmidt)]

The ticket should remain open to document the fact that the root ports are doing something different than every other port that uses the select portgroup, until they stop doing that.

[cjones051073 (Chris Jones)]

Then this ticket is going to stay open for a while, as I have no plans to change it. Do we really want that ?

[cjones051073 (Chris Jones)]

OK, sorry, I understand now. You mean until such a time as something is in base to support it, so then they change change. That is reasonable enough I suppose.

[cjones051073 (Chris Jones)]

Does trac have a way of labelling a ticket as dependent on the resolution of another one ? I cannot see it if it does. Other ticket systems I use have this and it would be useful in this case.

[ryandesign (Ryan Carsten Schmidt)]

I mean what I said. The root ports do something different with the select mechanism than any other ports that use the select mechanism: specifically, they run port select on the user's behalf. That is what this ticket is about. Why is root special? Why does root get to break the rules? If you think the rules are wrong (for example, if you think ports should be allowed to run port select), let's discuss it on the mailing list, reach a consensus, and if we decide that the rules need to change, then we need another ticket to track making the necessary changes to base, such as those Rainer proposed above to expose the port select functionality in the API.

[ryandesign (Ryan Carsten Schmidt)]

No, our Trac installation doesn't have a feature for tracking ticket dependencies.