uninstalling a selected port ...
Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current - postgresql93: file already exists petr% ls -la /opt/local/etc/select/postgresql/current lrwxr-xr-x 1 root admin 12 28 Feb 12:38 /opt/local/etc/select/postgresql/current - postgresql92 smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, Feb 28, 2014 at 8:44 AM, Jason Swails jason.swa...@gmail.comwrote: sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Except the implication of their preamble is that that file was left around by removing the postgres92 port, because port select isn't sufficiently integrated and isn't cleared when a `select`ed port is removed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, 2014-02-28 at 14:53 +0100, Peter Danecek wrote: On 28 Feb 2014, at 14:44, Jason Swails jason.swa...@gmail.com wrote: On Fri, 2014-02-28 at 14:33 +0100, Peter Danecek wrote: Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current- postgresql93: file already exists Try forcing the issue. sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Well, I understand your point and it would be fine if it is decided to leave ALL untouched. But then in expect consistent information, i.e. all should be left pointing to `postgresql92` (even if it does not exist), so at least you know the status. If I am informed that it point to `none` this should be the case. I believe it is consistent. As I understand it, the simlinks created by port select are not *owned* by the selected port. Since the port itself does not maintain these simlinks (but rather 'port select' does), there are good arguments to be made that the port should _not_ own simlinks created by select. As a result, uninstalling that port should not touch those simlinks. This results in the errors you saw. An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. All the best, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, Feb 28, 2014 at 9:30 AM, Peter Danecek peter.dane...@bo.ingv.itwrote: On 28 Feb 2014, at 15:17, Jason Swails jason.swa...@gmail.com wrote: An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. This does not work (tested). You cannot set new pointers after uninstalling the port, not even to none. I have not tested forcing but remove the link to be able to use port select again. I am not sure this is only aesthetic! I'll agree with you now. -f should only be required if you do something atypical -- I don't like it as part of a required workflow. I've needed it before, but that was when I deleted /opt/local to reinstall MacPorts and file collisions occurred inside other folders (like /Applications/MacPorts). (should we move this discussion on devel?) I have no opinion here. I'm not subscribed to that list and do not actively help to maintain MacPorts... All the best, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 15:38, Clemens Lang c...@macports.org wrote: Hi, I believe it is consistent. As I understand it, the simlinks created by port select are not *owned* by the selected port. Since the port itself does not maintain these simlinks (but rather 'port select' does), there are good arguments to be made that the port should _not_ own simlinks created by select. As a result, uninstalling that port should not touch those simlinks. This results in the errors you saw. That's correct. However, the symlinks are currently not owned by the corresponding *_select port either, which they probably should and which would solve this problem to some extent, because uninstalling the *_select port would just remove the symlinks. Give ownership of the symlink to the *_select port probably makes sense, but would not resolve the described problem, right? Of course we could also add a check to MacPorts that would somehow notice that you're currently deactivating a port that's currently selected, but that wouldn't be easy, because updates of a port also deactivate (and later re-activate) it and shouldn't destroy your selection. Okay, so leaving the pointer to the deactivated port makes sense to keep it valid after reactivation. But would be a simple solution to make it possible to set the a new version of the port even in the described case, i.e. overwrite the symlink when requested by the user (without -f flag, no need to remove the symlink before). This operation should be always possible, independent of the fact that some port is installed or not. The other thing is, if this pointer is really set to an deactivated/uninstalled port, which (see above) we judge is a valid state, this should be reported to the user. I the concrete case: sudo port select --list postgresql Available versions for postgresql: none postgresql93 Active version set to / Currently not available versions for postgresql: postgresql92 (active) Or some similar output. This would imply the ticket would be compiled against … (well) *_select, the select port group ??? Thanks! ~petr I was actually planning on registering the created symlinks to the *_select ports for a while now so trace mode can reliably hide stuff created by the select feature while building (because the selection should never affect how a port builds). -- Clemens Lang smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 15:17, Jason Swails jason.swa...@gmail.com wrote: An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. This does not work (tested). You cannot set new pointers after uninstalling the port, not even to none. I have not tested forcing but remove the link to be able to use port select again. I am not sure this is only aesthetic! (should we move this discussion on devel?) ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 14:44, Jason Swails jason.swa...@gmail.com wrote: On Fri, 2014-02-28 at 14:33 +0100, Peter Danecek wrote: Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current- postgresql93: file already exists Try forcing the issue. sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Well, I understand your point and it would be fine if it is decided to leave ALL untouched. But then in expect consistent information, i.e. all should be left pointing to `postgresql92` (even if it does not exist), so at least you know the status. If I am informed that it point to `none` this should be the case. And I am not sure if setting the current link to `none` would harm here. ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
