Opened 10 years ago
Last modified 7 years ago
#44509 new defect
selfupdate tried to tell me to run selfupdate again
Reported by: | dave@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.3.1 |
Keywords: | Cc: | ||
Port: |
Description
I ran port selfupdate, which said this, just before exiting:
Not all sources could be fully synced using the old version of MacPorts. Please run selfupdate again now that MacPorts base has been updated.
We see a lot of text in a day, including a lot of stuff we skim over because it serves only really as a textual replacement for a progress bar. So it's hard for such text, which is basically crying wolf, to get our attention. So I missed above text that selfupdate printed. BTW, here the text is set off in a box by itself, indented. In real life it just looked like more debug/verbose blah blah output.
In any case, if selfupdate knows enough to print that message, it knows enough to do the second pass itself and should do so.
Change History (6)
comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 follow-up: 3 Changed 10 years ago by dave@…
MacPorts could write out a tiny trampoline program to /tmp, make it unwritable then setuid root, exec it, then it execs (the new) MacPorts, which deletes the trampoline program and continues. Code to do this is probably in a library somewhere, or it should be.
This trick would not only solve the problem posed in this report, but it would allow selfupdate to become an option, not a command to be run by itself and waited for.
Seems like a minor price to pay for a better user experience, no?
Many apps on the Mac can update themselves. Firefox, for one.
comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to dave@…:
MacPorts could write out a tiny trampoline program to /tmp, make it unwritable then setuid root, exec the trampoline, then the trampoline execs (the new) MacPorts, which deletes the trampoline program and continues. Code to do this is probably in a library somewhere, or it should be.
That sounds plausible. Someone should write code to do this and see what happens. Or we may want to instead implement SummerOfCode#self-management
This trick would not only solve the problem posed in this report, but it would allow selfupdate to become an option, not a command to be run by itself and waited for.
An option... are you suggesting that instead of updating MacPorts by running "sudo port selfupdate", they would update by running, to pick a flag at random, "sudo port -z"? Why would this be an improvement? I would prefer the above-suggested improvement, that it would be updated by running "sudo port upgrade MacPorts".
comment:4 Changed 10 years ago by dave@…
I suppose
sudo /opt/local/bin/port -u upgrade outdated
isn't an earthshaking improvement because one could do this and walk away while it chugs away.
sudo /opt/local/bin/port selfupdate && sudo /opt/local/bin/port upgrade outdated
It's just that mental modelwise, why should anyone have to remember to do a selfupdate, have to make the decision "has it been long enough so I should do a selfupdate?", and why should anyone (other than a developer of the port command) have to think of selfupdate as a separate step that has to be run by itself?
For that matter, why can't the server give a quick yes/no answer to the question "is selfupdate necessary?" so that my MacPorts client can do selfupdate if necessary, without undo performance penalty? If this performance issue could be solved, then there should be an option to tell MacPorts NOT to do a selfupdate, as selfupdate should be the default.
comment:5 Changed 9 years ago by mf2k (Frank Schima)
Component: | ports → base |
---|---|
Keywords: | selfupdate removed |
comment:6 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Here are some reasons why we do not automatically run selfupdate:
selfupdate takes a nonzero amount of time to determine whether a new version of MacPorts base is available. If you are running many separate port commands, you don't want to incur that performance penalty for every command you run. The organization providing our master rsync server also probably doesn't want to serve that additional network traffic.
selfupdate currently requires access to an rsync server. This does not work for all users, particularly those on corporate networks with restrictive firewalls that prohibit rsync traffic. Those users need to use alternatives for selfupdate, so it wouldn't be helpful for us to automatically run selfupdate for them, since it would just fail.
selfupdate also updates the ports tree. It's not uncommon for dozens of changes to be made to the ports tree every day. If you want to receive these changes as quickly as possible, you may want to run selfupdate once every day that you use MacPorts. If you don't care about being that up-to-date, just install ports as needed. If you haven't run selfupdate in two weeks, MacPorts will remind you to do so.
The idea of providing a combined selfupdate-and-upgrade-outdated command has been proposed in #56134.
This ticket should remain open to explore the "trampoline program" idea you proposed.
The problem is that the first selfupdate updated MacPorts itself, and the ports now need to be reindexed using that new build of MacPorts, so we need to exit and have you re-run the command a second time.