"port outdated" broken in trunk
In trunk @29497 "port outdated" returns the list of outdated ports: $ port outdated The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ However in trunk @29502 "port outdated" finds nothing: $ port outdated None of the specified ports are outdated. $ I can still query individual ports: $ port outdated wxWidgets The following installed ports are outdated: wxWidgets 2.8.4_2 < 2.8.6_1 $ Or all installed ports: $ port outdated installed The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ But is this change in behavior intentional? There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
Those two commits have nothing to do with this. I'm as mystified by this as you are. On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports:
$ port outdated The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $
However in trunk @29502 "port outdated" finds nothing:
$ port outdated None of the specified ports are outdated. $
I can still query individual ports:
$ port outdated wxWidgets The following installed ports are outdated: wxWidgets 2.8.4_2 < 2.8.6_1 $
Or all installed ports:
$ port outdated installed The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $
But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
Those two commits have nothing to do with this. I'm as mystified by this as you are.
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged. I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc. Chris
On Oct 5, 2007, at 8:06 AM, Chris Pickel wrote:
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
Those two commits have nothing to do with this. I'm as mystified by this as you are.
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged.
I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc.
Yes, it seems to be the change in usage of global_options that broke this. The port(1) code in port.tcl is written to assume global_options is its own private variable (which it is: was). Note the use global_options_base, too, from which global_options is reset during processing of multiple commands. James
Ah hah. It seems port(1) is using the global options array to hold its own private options as well. There are two possible solutions. The first is to make port(1) stop using macports::global_option_isset and make it just check the global_options array directly. The second is to make port(1) use a separate array for its private options and check that directly. On Oct 5, 2007, at 11:06 AM, Chris Pickel wrote:
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
Those two commits have nothing to do with this. I'm as mystified by this as you are.
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged.
I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc.
Chris
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Oct 5, 2007, at 10:15, Kevin Ballard wrote:
On Oct 5, 2007, at 11:06 AM, Chris Pickel wrote:
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
Those two commits have nothing to do with this. I'm as mystified by this as you are.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged.
I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc.
Ah hah. It seems port(1) is using the global options array to hold its own private options as well. There are two possible solutions. The first is to make port(1) stop using macports::global_option_isset and make it just check the global_options array directly. The second is to make port(1) use a separate array for its private options and check that directly.
Any progress on this? "port installed" is broken too, by the way (shows nothing installed). "port installed installed" works, though. It looks like a bug has already been submitted for this issue: http://trac.macports.org/projects/macports/ticket/12837
On Oct 11, 2007, at 10:05 PM, Ryan Schmidt wrote:
On Oct 5, 2007, at 10:15, Kevin Ballard wrote:
On Oct 5, 2007, at 11:06 AM, Chris Pickel wrote:
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
Those two commits have nothing to do with this. I'm as mystified by this as you are.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged.
I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc.
Ah hah. It seems port(1) is using the global options array to hold its own private options as well. There are two possible solutions. The first is to make port(1) stop using macports::global_option_isset and make it just check the global_options array directly. The second is to make port(1) use a separate array for its private options and check that directly.
Any progress on this?
"port installed" is broken too, by the way (shows nothing installed). "port installed installed" works, though.
It looks like a bug has already been submitted for this issue:
I think this is Kevin's to fix, since his checkin broke it? A short term workaround is probably to use "port installed all" or "port outdated all"? James
On Oct 12, 2007, at 08:26, James Berry wrote:
On Oct 11, 2007, at 10:05 PM, Ryan Schmidt wrote:
On Oct 5, 2007, at 10:15, Kevin Ballard wrote:
On Oct 5, 2007, at 11:06 AM, Chris Pickel wrote:
On 05 Oct, 2007, at 10:53, Kevin Ballard wrote:
On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote:
In trunk @29497 "port outdated" returns the list of outdated ports: ... However in trunk @29502 "port outdated" finds nothing: ... But is this change in behavior intentional?
There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down.
Those two commits have nothing to do with this. I'm as mystified by this as you are.
I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged.
I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc.
Ah hah. It seems port(1) is using the global options array to hold its own private options as well. There are two possible solutions. The first is to make port(1) stop using macports::global_option_isset and make it just check the global_options array directly. The second is to make port(1) use a separate array for its private options and check that directly.
Any progress on this?
"port installed" is broken too, by the way (shows nothing installed). "port installed installed" works, though.
It looks like a bug has already been submitted for this issue:
I think this is Kevin's to fix, since his checkin broke it? A short term workaround is probably to use "port installed all" or "port outdated all"?
I think the quicker workaround is "port installed installed" and "port outdated installed", and Chris pointed out that Juan Manuel's commit in r29191 is the one that changed the API...
On Oct 14, 2007, at 8:00 PM, Ryan Schmidt wrote:
I think the quicker workaround is "port installed installed" and "port outdated installed", and Chris pointed out that Juan Manuel's commit in r29191 is the one that changed the API...
Both Kevin and I tweaked the macports1.0 API in several commits in order to make scripting of that layer (basically what port.tcl and any other API client does) considerably easier. I'll try looking for a fix to this regression (is there a ticket number for it?). Regards,... -jmpp
On Oct 15, 2007, at 03:48, Juan Manuel Palacios wrote:
On Oct 14, 2007, at 8:00 PM, Ryan Schmidt wrote:
I think the quicker workaround is "port installed installed" and "port outdated installed", and Chris pointed out that Juan Manuel's commit in r29191 is the one that changed the API...
Both Kevin and I tweaked the macports1.0 API in several commits in order to make scripting of that layer (basically what port.tcl and any other API client does) considerably easier. I'll try looking for a fix to this regression (is there a ticket number for it?).
Thanks. The ticket is http://trac.macports.org/projects/macports/ticket/12837
participants (5)
-
Chris Pickel
-
James Berry
-
Juan Manuel Palacios
-
Kevin Ballard
-
Ryan Schmidt