Re: [21414] trunk/dports/graphics/gd/Portfile
Port gd2 is at 2.0.33. If gd 1.x is no longer needed couldn't we just delete it and use the gd2 port? Mark macports-dev@lists.macosforge.org on Tuesday, January 23, 2007 at 3:36 PM -0800 wrote:
Revision [ http://trac.macosforge.org/projects/macports/changeset/21414 ]21414 Author toby@macports.org Date 2007-01-23 15:36:22 -0800 (Tue, 23 Jan 2007)
Log Message
gd 2.0.33
Modified Paths
[ fcp://@bubbs.biola.edu,%235000280/MailBox/%23196897907#trunkdportsgraphicsgdPortfile ]trunk/dports/graphics/gd/Portfile
Diff
Modified: trunk/dports/graphics/gd/Portfile (21413 => 21414)
--- trunk/dports/graphics/gd/Portfile 2007-01-23 23:22:13 UTC (rev 21413) +++ trunk/dports/graphics/gd/Portfile 2007-01-23 23:36:22 UTC (rev 21414) @@ -2,9 +2,9 @@
PortSystem 1.0 name gd -version 1.8.4 -set libver 1.8 -revision 3 +version 2.0.33 +set libver 2.0.0 +revision 4 categories graphics maintainers michaelm@opendarwin.org description GD creates PNG and JPEG images, among other formats @@ -19,17 +19,11 @@
On Jan 23, 2007, at 17:52, Mark Duling wrote:
Port gd2 is at 2.0.33. If gd 1.x is no longer needed couldn't we just delete it and use the gd2 port?
Aaaa! Yes, why was r21414 committed? I would have thought the point of having a gd and a gd2 port was to keep the 1.x and 2.x series separate. There may be some cases where programs that worked with gd1 won't work with gd2, according to the gd faq: http://libgd.org/FAQ#Why_doesn. 27t_my_gd_1.x_program_work_well_with_gd_2.x.3F How do we discover which ports, if any, depend on gd? "port echo depends_lib:gd" does not seem to work (produces an error).
macports-dev@lists.macosforge.org on Tuesday, January 23, 2007 at 3:36 PM -0800 wrote:
Revision [ http://trac.macosforge.org/projects/macports/changeset/21414 ]21414 Author toby@macports.org Date 2007-01-23 15:36:22 -0800 (Tue, 23 Jan 2007)
Log Message
gd 2.0.33
Modified Paths
[ fcp://@bubbs.biola.edu,%235000280/MailBox/% 23196897907#trunkdportsgraphicsgdPortfile ]trunk/dports/graphics/gd/Portfile
Diff
Modified: trunk/dports/graphics/gd/Portfile (21413 => 21414)
--- trunk/dports/graphics/gd/Portfile 2007-01-23 23:22:13 UTC (rev 21413) +++ trunk/dports/graphics/gd/Portfile 2007-01-23 23:36:22 UTC (rev 21414) @@ -2,9 +2,9 @@
PortSystem 1.0 name gd -version 1.8.4 -set libver 1.8 -revision 3 +version 2.0.33 +set libver 2.0.0 +revision 4 categories graphics maintainers michaelm@opendarwin.org description GD creates PNG and JPEG images, among other formats @@ -19,17 +19,11 @@
Ryan Schmidt <ryandesign@macports.org> on Tuesday, January 23, 2007 at 10:15 PM -0800 wrote:
Port gd2 is at 2.0.33. If gd 1.x is no longer needed couldn't we just delete it and use the gd2 port?
Aaaa! Yes, why was r21414 committed? I would have thought the point of having a gd and a gd2 port was to keep the 1.x and 2.x series separate.
There may be some cases where programs that worked with gd1 won't work with gd2, according to the gd faq:
http://libgd.org/FAQ#Why_doesn. 27t_my_gd_1.x_program_work_well_with_gd_2.x.3F
How do we discover which ports, if any, depend on gd? "port echo depends_lib:gd" does not seem to work (produces an error).
I have found grepping portindex and such to give confusing results, maybe I just don't know the right method though. I just did a 'port deps all' and searched the output. I see no dependencies on gd 1.x at all and it seems unlikely there will be new ports depending on it. I think it is nukeworthy. Nuke! Nuke! Nuke! Nuke! Mark
On Jan 24, 2007, at 00:39, Mark Duling wrote:
How do we discover which ports, if any, depend on gd? "port echo depends_lib:gd" does not seem to work (produces an error).
I have found grepping portindex and such to give confusing results, maybe I just don't know the right method though. I just did a 'port deps all' and searched the output. I see no dependencies on gd 1.x at all and it seems unlikely there will be new ports depending on it. I think it is nukeworthy. Nuke! Nuke! Nuke! Nuke!
Thanks for "port deps all"; didn't know that one. It took a long time to run, but I have now determined that there is exactly one port that depends on gd: cvsgraph. The port is at version 1.5.0. The changelog for version 1.5.2 includes "Fix configure script to detect gd-2 problems" so perhaps the current version of cvsgraph, 1.6.1, will work properly with gd2. cvsgraph has no maintainer, and I don't use CVS, so perhaps someone else could take a look at whether cvsgraph can be updated to 1.6.1 and made to use gd2 instead of gd. Then we can delete the gd port. "port deps" is, however, broken. The output of "port deps all" includes this bit: cvsgraph has build dependencies on: hicolor-icon-theme cvsgraph has library dependencies on: gd cvsgraph has runtime dependencies on: python24 rpm yum cvslock has build dependencies on: hicolor-icon-theme cvslock has library dependencies on: gd cvslock has runtime dependencies on: python24 rpm yum It says cvslock has library dependencies on gd, but it has no such thing. "port deps" appears to simply not be clearing out the variables when moving to the next port. The *previous* port (cvsgraph) had library dependencies on gd, and because cvslock has no library dependencies on anything, it still prints the info from the previous port. Same in fact goes for the build and runtime dependencies: neither of these ports have any kind of dependencies on hicolor-icon-theme, python24, rpm or yum. This is all made obvious by calling "port deps" with these two ports in this order, then in the reverse order: $ port deps cvsgraph cvslock cvsgraph has library dependencies on: gd cvslock has library dependencies on: gd $ port deps cvslock cvsgraph cvslock has no dependencies cvsgraph has library dependencies on: gd I am unable to find a bug in Trac about this problem. (Or rather, I am unable to divine a way to search Trac to see if this problem has already been reported.) Does anyone know if this has already been reported? Or should I just open a new bug report?
On Jan 24, 2007, at 01:50, Ryan Schmidt wrote:
I have now determined that there is exactly one port that depends on gd: cvsgraph. The port is at version 1.5.0. The changelog for version 1.5.2 includes "Fix configure script to detect gd-2 problems" so perhaps the current version of cvsgraph, 1.6.1, will work properly with gd2. cvsgraph has no maintainer, and I don't use CVS, so perhaps someone else could take a look at whether cvsgraph can be updated to 1.6.1 and made to use gd2 instead of gd. Then we can delete the gd port.
You know what? I just did "sudo port install cvsgraph" and it happily downloaded and installed cvsgraph 1.5.0, without downloading or installing gd, even though cvsgraph allegedly has library dependencies on it. So I don't know what to make of that.
Ryan Schmidt <ryandesign@macports.org> on Tuesday, January 23, 2007 at 11:50 PM -0800 wrote:
Thanks for "port deps all"; didn't know that one. It took a long time to run, but I have now determined that there is exactly one port that depends on gd: cvsgraph. The port is at version 1.5.0. The changelog for version 1.5.2 includes "Fix configure script to detect gd-2 problems" so perhaps the current version of cvsgraph, 1.6.1, will work properly with gd2. cvsgraph has no maintainer, and I don't use CVS, so perhaps someone else could take a look at whether cvsgraph can be updated to 1.6.1 and made to use gd2 instead of gd. Then we can delete the gd port.
"port deps" is, however, broken. The output of "port deps all" includes this bit:
cvsgraph has build dependencies on: hicolor-icon-theme cvsgraph has library dependencies on: gd cvsgraph has runtime dependencies on: python24 rpm yum cvslock has build dependencies on: hicolor-icon-theme cvslock has library dependencies on: gd cvslock has runtime dependencies on: python24 rpm yum
It says cvslock has library dependencies on gd, but it has no such thing. "port deps" appears to simply not be clearing out the variables when moving to the next port. The *previous* port (cvsgraph) had library dependencies on gd, and because cvslock has no library dependencies on anything, it still prints the info from the previous port. Same in fact goes for the build and runtime dependencies: neither of these ports have any kind of dependencies on hicolor-icon-theme, python24, rpm or yum. This is all made obvious by calling "port deps" with these two ports in this order, then in the reverse order:
$ port deps cvsgraph cvslock cvsgraph has library dependencies on: gd cvslock has library dependencies on: gd $ port deps cvslock cvsgraph cvslock has no dependencies cvsgraph has library dependencies on: gd
I am unable to find a bug in Trac about this problem. (Or rather, I am unable to divine a way to search Trac to see if this problem has already been reported.) Does anyone know if this has already been reported? Or should I just open a new bug report?
It sounds similar to this. http://trac.macosforge.org/projects/macports/ticket/10936 II think i needs a better summary line because it is hard to find. Not sure what is better though. Mark
Ryan Schmidt <ryandesign@macports.org> on Tuesday, January 23, 2007 at 11:55 PM -0800 wrote:
I have now determined that there is exactly one port that depends on gd: cvsgraph. The port is at version 1.5.0. The changelog for version 1.5.2 includes "Fix configure script to detect gd-2 problems" so perhaps the current version of cvsgraph, 1.6.1, will work properly with gd2. cvsgraph has no maintainer, and I don't use CVS, so perhaps someone else could take a look at whether cvsgraph can be updated to 1.6.1 and made to use gd2 instead of gd. Then we can delete the gd port.
You know what? I just did "sudo port install cvsgraph" and it happily downloaded and installed cvsgraph 1.5.0, without downloading or installing gd, even though cvsgraph allegedly has library dependencies on it. So I don't know what to make of that.
I *think* the old style dependency lib:libgd:gd would be satisfied by either gd 1.x or 2.x. Perhaps the configure script does not try to detect it but leaves it to the user to make sure it is installed. Mark
On Jan 24, 2007, at 01:56, Mark Duling wrote:
$ port deps cvsgraph cvslock cvsgraph has library dependencies on: gd cvslock has library dependencies on: gd $ port deps cvslock cvsgraph cvslock has no dependencies cvsgraph has library dependencies on: gd
I am unable to find a bug in Trac about this problem. (Or rather, I am unable to divine a way to search Trac to see if this problem has already been reported.) Does anyone know if this has already been reported? Or should I just open a new bug report?
It sounds similar to this.
http://trac.macosforge.org/projects/macports/ticket/10936
II think i needs a better summary line because it is hard to find. Not sure what is better though.
Thanks, that looks like the right bug. I've added some notes to it.
participants (2)
-
Mark Duling
-
Ryan Schmidt