Automatic out-of-dateness checking for base and ports tree
With some of the fundamental changes that have gone on in MacPorts 1.4.x since the 1.4.0 release, and since we only do downloadable disk images for the major releases, we have this problem that a lot of people seem to be downloading 1.4.0 and attempting to use it before selfupdating and reporting a whole slew of problems to the list which we then have to diagnose and it's always the same suggestion to fix it: update MacPorts. Or, people are installing MacPorts and not realizing that they have to periodically inform it to update itself. People may be under one of two reasonable expectations: 1) software keeps itself up to date, or 2) software that is not updated continues to function. MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve. Below is one such message. Steve says it might be nice if MacPorts would suggest updating itself if it encounters an error. I think we can probably do better than that, can't we? Couldn't we have MacPorts periodically (weekly?) check if a new version of MacPorts is available, and alert the user to this fact if they haven't run selfupdate themselves? I don't mean a cron task; I just mean, if the user happens to be running "port" right now and it's been a week since the last selfupdate, then print a message. There should be a file somewhere indicating the last time MacPorts checked its version, and this file would not exist for new installs, such that the first time somebody runs "port", it would check to see if it's outdated. It wouldn't have to update itself automatically. But it should inform the user if it is outdated. For those who are paranoid about apps phoning home, there could be a way to disable this feature. Something similar could be done for the ports tree, but for that we probably don't even need to check the server -- we know that ports get updated very frequently. We could just store the last time that a sync was done, and if it's been awhile (a day? a week?), alert the user that they should sync again. Thoughts? Begin forwarded message:
From: Steve Dekorte <steve@dekorte.com> Date: June 7, 2007 02:14:49 CDT To: Ryan Schmidt <ryandesign@macports.org> Cc: macports-users@lists.macosforge.org Subject: Re: llvm port problem
On 6 Jun 2007, at 06:36 pm, Ryan Schmidt wrote:
I tried it just now, and llvm 2.0_0 installs just fine for me on Intel Core 2 Duo with Mac OS X 10.4.9 and MacPorts 1.4.42 and Xcode 2.4.1.
What MacPorts version do you have? Is your ports tree up to date? Try "sudo port selfupdate" to update both.
Do you have the latest Xcode?
Thanks Ryan, the port version was the problem. It might save some frustration and support requests if port suggest what you did when a port fails.
Couldn't a version check be done when a user attempts a sudo port install <somesoftware> and only if the MacPorts version is up to date, then the install goes ahead, otherwise it echoes a "please update" warning? Mark -- At 17:10 -0500 7/6/07, Ryan Schmidt wrote:
With some of the fundamental changes that have gone on in MacPorts 1.4.x since the 1.4.0 release, and since we only do downloadable disk images for the major releases, we have this problem that a lot of people seem to be downloading 1.4.0 and attempting to use it before selfupdating and reporting a whole slew of problems to the list which we then have to diagnose and it's always the same suggestion to fix it: update MacPorts. Or, people are installing MacPorts and not realizing that they have to periodically inform it to update itself. People may be under one of two reasonable expectations: 1) software keeps itself up to date, or 2) software that is not updated continues to function. MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve.
Below is one such message. Steve says it might be nice if MacPorts would suggest updating itself if it encounters an error. I think we can probably do better than that, can't we? Couldn't we have MacPorts periodically (weekly?) check if a new version of MacPorts is available, and alert the user to this fact if they haven't run selfupdate themselves? I don't mean a cron task; I just mean, if the user happens to be running "port" right now and it's been a week since the last selfupdate, then print a message. There should be a file somewhere indicating the last time MacPorts checked its version, and this file would not exist for new installs, such that the first time somebody runs "port", it would check to see if it's outdated.
It wouldn't have to update itself automatically. But it should inform the user if it is outdated. For those who are paranoid about apps phoning home, there could be a way to disable this feature.
Something similar could be done for the ports tree, but for that we probably don't even need to check the server -- we know that ports get updated very frequently. We could just store the last time that a sync was done, and if it's been awhile (a day? a week?), alert the user that they should sync again.
Thoughts?
Begin forwarded message:
From: Steve Dekorte <steve@dekorte.com> Date: June 7, 2007 02:14:49 CDT To: Ryan Schmidt <ryandesign@macports.org> Cc: macports-users@lists.macosforge.org Subject: Re: llvm port problem
On 6 Jun 2007, at 06:36 pm, Ryan Schmidt wrote:
I tried it just now, and llvm 2.0_0 installs just fine for me on Intel Core 2 Duo with Mac OS X 10.4.9 and MacPorts 1.4.42 and Xcode 2.4.1.
What MacPorts version do you have? Is your ports tree up to date? Try "sudo port selfupdate" to update both.
Do you have the latest Xcode?
Thanks Ryan, the port version was the problem. It might save some frustration and support requests if port suggest what you did when a port fails.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On Jun 7, 2007, at 20:06, Mark Hattam wrote:
Couldn't a version check be done when a user attempts a
sudo port install <somesoftware>
and only if the MacPorts version is up to date, then the install goes ahead, otherwise it echoes a "please update" warning?
Something like that is what I was thinking, yes. However, I wouldn't limit it to "port install"; I'd do it on any "port" command. Also, I wouldn't check every time, as that would be an unnecessary load on the server. That's why I suggested a timestamp file and checking only once a day, say.
On 07 Jun, 2007, at 18:10, Ryan Schmidt wrote:
MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve.
You've identified a key point here: the problem occurs when the ports tree is synced without a selfupdate. It seems that this could be solved by keeping a file containing the target version in the ports tree. That file would be compared against ${prefix}/etc/macports/ mp_version to see if the installed version is new enough. This would require no periodic checking, other than the `port sync` which has to happen anyway. Nor would there be any possibility of the user having problems in the intermittent period between the server update and their check. Chris
On Jun 7, 2007, at 21:01, Chris Pickel wrote:
On 07 Jun, 2007, at 18:10, Ryan Schmidt wrote:
MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve.
You've identified a key point here: the problem occurs when the ports tree is synced without a selfupdate. It seems that this could be solved by keeping a file containing the target version in the ports tree. That file would be compared against ${prefix}/etc/ macports/mp_version to see if the installed version is new enough.
This would require no periodic checking, other than the `port sync` which has to happen anyway. Nor would there be any possibility of the user having problems in the intermittent period between the server update and their check.
Why do we even have two commands -- sync and selfupdate? Why can't we just have a single command which always does the right thing?
participants (3)
-
Chris Pickel
-
Mark Hattam
-
Ryan Schmidt