Re: [29735] trunk/dports/x11/gtk-engines2/Portfile
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log Message
Update dependencies based on trace output -depends_build port:p5-xml-parser
-depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5-xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ? yves
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on trace output-depends_build port:p5-xml-parser -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ? yves
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only." -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Le 07-10-08 à 14:45, N_Ox a écrit :
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on trace output-depends_build port:p5-xml-parser -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ? yves
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only."
Why not ? yves
On Oct 8, 2007, at 14:49, Yves de Champlain wrote:
Le 07-10-08 à 14:45, N_Ox a écrit :
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on trace output-depends_build port:p5-xml-parser -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff
Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ?
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only."
Why not ?
If, as in nox's hypothetical example, A really does depend on B and C, then both B and C should be listed as dependencies of A. C should not be excluded from the dependencies of A just because B currently depends on C. B might stop depending on C at some point, at which point A would break if A really does itself independently need C. I do not know if any of this applies to the commit on which this thread is based.
On Oct 8, 2007, at 3:57 PM, Ryan Schmidt wrote:
On Oct 8, 2007, at 14:49, Yves de Champlain wrote:
Le 07-10-08 à 14:45, N_Ox a écrit :
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on trace output-depends_build port:p5-xml- parser -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5-xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff
Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ?
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only."
Why not ?
If, as in nox's hypothetical example, A really does depend on B and C, then both B and C should be listed as dependencies of A. C should not be excluded from the dependencies of A just because B currently depends on C. B might stop depending on C at some point, at which point A would break if A really does itself independently need C.
But if A only depends on C through B's dependency on it, I don't really see why such link should be listed explicitly in A's dependency list. As in the gtk-engines2 example above: does such port really itself *explicitly* depend on glib2 (that is, would the sources fail to preprocess were the glib headers moved aside temporarily, or to link in the case of missing glib libraries)? Or is the glib2 dependency listed only 'cause gtk2 itself depends on it? In case of the former, the dependency needs to be clearly stated; in case of the latter, it's unnecessary bloat in my opinion. Regards,... -jmpp
On Oct 8, 2007, at 16:02, Juan Manuel Palacios wrote:
On Oct 8, 2007, at 3:57 PM, Ryan Schmidt wrote:
On Oct 8, 2007, at 14:49, Yves de Champlain wrote:
Le 07-10-08 à 14:45, N_Ox a écrit :
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on trace output-depends_build port:p5-xml- parser -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5-xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + port:libpng \ + port:pango \ + port:tiff
Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ?
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only."
Why not ?
If, as in nox's hypothetical example, A really does depend on B and C, then both B and C should be listed as dependencies of A. C should not be excluded from the dependencies of A just because B currently depends on C. B might stop depending on C at some point, at which point A would break if A really does itself independently need C.
But if A only depends on C through B's dependency on it, I don't really see why such link should be listed explicitly in A's dependency list.
I agree with that also.
As in the gtk-engines2 example above: does such port really itself *explicitly* depend on glib2 (that is, would the sources fail to preprocess were the glib headers moved aside temporarily, or to link in the case of missing glib libraries)? Or is the glib2 dependency listed only 'cause gtk2 itself depends on it? In case of the former, the dependency needs to be clearly stated; in case of the latter, it's unnecessary bloat in my opinion.
Right, that should be investigated. I'm not familiar enough with gtk- engines2 to know.
A couple of notes on this port: This big dependency chain was introduced because of a note that gtk- engines2 broke if it was installed on a clean machine (ie one that did not have GNOME installed on it first). After the gettext upgrade fiasco, where I was maintaining some ports (port A) where the dependency chain was A => B => C => D => E => gettext, but all ports A-E were linked to it by E's requirement, only E had the explicit dependency and so A-D had to be manually reinstalled. It seems smart to be overly explicit about dependencies in these cases. That said, there may be some overkill here, but I'm not sure how to determine what is and what isn't overkill. On 8 Oct 2007, at 17:43, Ryan Schmidt wrote:
On Oct 8, 2007, at 16:02, Juan Manuel Palacios wrote:
On Oct 8, 2007, at 3:57 PM, Ryan Schmidt wrote:
On Oct 8, 2007, at 14:49, Yves de Champlain wrote:
Le 07-10-08 à 14:45, N_Ox a écrit :
Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
Le 07-10-08 à 05:34, source_changes@macosforge.org a écrit :
> Revision 29735 Author rhwood@macports.org Date 2007-10-08 > 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate > dependencies based on trace output-depends_build port:p5-xml- > parser > -depends_lib port:gtk2 +depends_build \ + port:expat \ + > port:p5-xml-parser \ + port:perl5.8 +depends_lib \ + port:atk > \ + port:cairo \ + port:fontconfig \ + port:freetype \ + > port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + > port:libiconv \ + port:libpng \ + port:pango \ + port:tiff
Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ?
It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only."
Why not ?
If, as in nox's hypothetical example, A really does depend on B and C, then both B and C should be listed as dependencies of A. C should not be excluded from the dependencies of A just because B currently depends on C. B might stop depending on C at some point, at which point A would break if A really does itself independently need C.
But if A only depends on C through B's dependency on it, I don't really see why such link should be listed explicitly in A's dependency list.
I agree with that also.
As in the gtk-engines2 example above: does such port really itself *explicitly* depend on glib2 (that is, would the sources fail to preprocess were the glib headers moved aside temporarily, or to link in the case of missing glib libraries)? Or is the glib2 dependency listed only 'cause gtk2 itself depends on it? In case of the former, the dependency needs to be clearly stated; in case of the latter, it's unnecessary bloat in my opinion.
Right, that should be investigated. I'm not familiar enough with gtk-engines2 to know.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Le 9 oct. 07 à 03:30, Randall Wood a écrit :
A couple of notes on this port:
This big dependency chain was introduced because of a note that gtk- engines2 broke if it was installed on a clean machine (ie one that did not have GNOME installed on it first).
After the gettext upgrade fiasco, where I was maintaining some ports (port A) where the dependency chain was A => B => C => D => E => gettext, but all ports A-E were linked to it by E's requirement, only E had the explicit dependency and so A-D had to be manually reinstalled. It seems smart to be overly explicit about dependencies in these cases.
That said, there may be some overkill here, but I'm not sure how to determine what is and what isn't overkill.
I usually go through the configure.(ac|in) file and grep sources around for #include preprocessor directives to figure out which are real dependencies and which aren't.
On 8 Oct 2007, at 17:43, Ryan Schmidt wrote:
<snip>
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com
-- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Le 07-10-09 à 02:39, N_Ox a écrit :
Le 9 oct. 07 à 03:30, Randall Wood a écrit :
A couple of notes on this port:
This big dependency chain was introduced because of a note that gtk-engines2 broke if it was installed on a clean machine (ie one that did not have GNOME installed on it first).
After the gettext upgrade fiasco, where I was maintaining some ports (port A) where the dependency chain was A => B => C => D => E => gettext, but all ports A-E were linked to it by E's requirement, only E had the explicit dependency and so A-D had to be manually reinstalled. It seems smart to be overly explicit about dependencies in these cases.
That said, there may be some overkill here, but I'm not sure how to determine what is and what isn't overkill.
I usually go through the configure.(ac|in) file and grep sources around for #include preprocessor directives to figure out which are real dependencies and which aren't.
Well, if it can help with port upgrade, this is definitely worth it. yves
participants (5)
-
Juan Manuel Palacios
-
N_Ox
-
Randall Wood
-
Ryan Schmidt
-
Yves de Champlain