Re: Dependency Problem of Upgrading Gnuplot: A Possible Bug
On Jul 24, 2007, at 10:44, M A wrote:
On 7/24/07, Ryan Schmidt wrote:
On Jul 23, 2007, at 21:44, Xin Liu wrote:
I've installed MacTex2007 and added /usr/texbin to $binpath in macports.conf. Then I've got no problem installing gnuplot, i.e. it does not try to install teTeX for me. However, if I invoke "sudo port upgrade gnuplot" (when the gnuplot is already the newest version), it starts to install teTeX. Why would it do this? Is there any problem in the implementation of the "upgrade" command, or did I miss anything in the configuration?
MacPorts is designed to use its own software, not any other software you may have installed elsewhere. See the FAQ:
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
Yes, but in the case of something like TeX, it's really kind of silly to force a user to install a rather huge system like teTeX which is, by the way, outdated and no longer being maintained, rather than allowing the user to use a more modern (and complete) distribution such as TeX Live. In fact, the port author, in principle, allows for this by including the library dependency as bin:tex:teTeX. The problem is that the mechanism of extending the path that macports checks to locate binaries (ie changing $binpath in a user's macports.conf) no longer works. It used to work in 1.4.?. Was this a deliberate design decision, or a bug introduced somewhere between the 1.4 and 1.5 macports?
I don't know; I'm sending your message back to the mailing list where somebody can hopefully answer it.
I checked the code for the "update" command: if I'm not wrong, the code lies in macports::upgrade{}. According to the following piece excerpted from the it: *** # library depends is upgraded if {[info exists portinfo(depends_lib)]} { foreach i $portinfo(depends_lib) { if {![llength [array get depscache $i]]} { set d [lindex [split $i :] end] set depscache($i) 1 upgrade $d $i $variationslist $optionslist depscache } } } *** It does not seem to check the external dependencies at all: all it does is to extract the port name from strings like "bin:tex:teTeX" and upgrade the port. It SHOULD have used something like _mportispresent{} to check whether the external dependencies have been satisfied. Or did I miss something? Best Regards, Xin Liu On 7/24/07, Ryan Schmidt <ryandesign@macports.org> wrote:
On Jul 24, 2007, at 10:44, M A wrote:
On 7/24/07, Ryan Schmidt wrote:
On Jul 23, 2007, at 21:44, Xin Liu wrote:
I've installed MacTex2007 and added /usr/texbin to $binpath in macports.conf. Then I've got no problem installing gnuplot, i.e. it does not try to install teTeX for me. However, if I invoke "sudo port upgrade gnuplot" (when the gnuplot is already the newest version), it starts to install teTeX. Why would it do this? Is there any problem in the implementation of the "upgrade" command, or did I miss anything in the configuration?
MacPorts is designed to use its own software, not any other software you may have installed elsewhere. See the FAQ:
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
Yes, but in the case of something like TeX, it's really kind of silly to force a user to install a rather huge system like teTeX which is, by the way, outdated and no longer being maintained, rather than allowing the user to use a more modern (and complete) distribution such as TeX Live. In fact, the port author, in principle, allows for this by including the library dependency as bin:tex:teTeX. The problem is that the mechanism of extending the path that macports checks to locate binaries (ie changing $binpath in a user's macports.conf) no longer works. It used to work in 1.4.?. Was this a deliberate design decision, or a bug introduced somewhere between the 1.4 and 1.5 macports?
I don't know; I'm sending your message back to the mailing list where somebody can hopefully answer it.
On Jul 24, 2007, at 5:27 PM, Xin Liu wrote:
I checked the code for the "update" command: if I'm not wrong, the code lies in macports::upgrade{}. According to the following piece excerpted from the it:
*** # library depends is upgraded if {[info exists portinfo(depends_lib)]} { foreach i $portinfo(depends_lib) { if {![llength [array get depscache $i]]} { set d [lindex [split $i :] end] set depscache($i) 1 upgrade $d $i $variationslist $optionslist depscache } } } ***
It does not seem to check the external dependencies at all: all it does is to extract the port name from strings like "bin:tex:teTeX" and upgrade the port. It SHOULD have used something like _mportispresent{} to check whether the external dependencies have been satisfied. Or did I miss something?
bin style dependencies are discouraged because of problems like this. The upgrade code (unless you pass it -n, which is what you want to be doing to fix this particular issue for yourself) needs to upgrade library dependencies (for cases where the new version of the port needs the newer library) and can't just check bin/lib style dependencies in that case (as the port could be installed, but is an older version). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Then what's the point of having the bin style dependencies? It's intended to solve the external dependency problem, otherwise the portfile author would use port style instead. With the current implementation of the "upgrade" command, the bin style is basically useless (because anyone who performs an upgrade will have the internal dependencies installed anyway), and there is no solution to accommodate external dependencies in a convenient way. "-n" is not an option, because it also prevents other dependencies that lie within macports from being upgraded. On the other hand, if the code never upgrades bin style dependencies, I cannot see any problem. I'd assume (almost, if not absolutely) every portfile author only uses bin style and lib style to accommodate external dependencies. If his/her package depends on other software that needs to be upgraded by macports, he/she should use port style instead. Best Regards, Xin Liu
bin style dependencies are discouraged because of problems like this.
The upgrade code (unless you pass it -n, which is what you want to be doing to fix this particular issue for yourself) needs to upgrade library dependencies (for cases where the new version of the port needs the newer library) and can't just check bin/lib style dependencies in that case (as the port could be installed, but is an older version).
-- Daniel J. Luke
On Jul 24, 2007, at 5:52 PM, Xin Liu wrote:
Then what's the point of having the bin style dependencies?
exactly ... that's why the use is discouraged ... it only causes problems.
It's intended to solve the external dependency problem, otherwise the portfile author would use port style instead. With the current implementation of the "upgrade" command, the bin style is basically useless (because anyone who performs an upgrade will have the internal dependencies installed anyway), and there is no solution to accommodate external dependencies in a convenient way.
Again, this is a reason why the usage is discouraged. I'm sure we'd be happy to include a patch to fix the issue if it doesn't create other issues as well (as your proposed change would, since it would also incorrectly prevent macports-provided ports from being upgraded if they were installed to satisfy a bin/lib style dependency).
"-n" is not an option, because it also prevents other dependencies that lie within macports from being upgraded.
You could just remove the dependency from the portfile, if -n won't work for you and you're insistent on using an external dependency.
On the other hand, if the code never upgrades bin style dependencies, I cannot see any problem. I'd assume (almost, if not absolutely) every portfile author only uses bin style and lib style to accommodate external dependencies.
The third part of a bin/lib style dependency is the port that can be used to meet the dependency.
If his/her package depends on other software that needs to be upgraded by macports, he/she should use port style instead.
Indeed, that's why (as I've said a few times now), the bin/lib style dependencies are discouraged in favor of port: style dependencies. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
At least, "install" and "upgrade" should be consistent. If "install" does not install something, "upgrade" should not touch that either; if "upgrade" would touch something, "install" should install that in the first place. Otherwise, there's too much confusion, and I don't think I'm the only one that is confused. As for the policy of "including everything in macports", I don't buy it, but it's another story and may be discussed in separate threads. Best Regards, Xin Liu
bin style dependencies are discouraged because of problems like this.
The upgrade code (unless you pass it -n, which is what you want to be doing to fix this particular issue for yourself) needs to upgrade library dependencies (for cases where the new version of the port needs the newer library) and can't just check bin/lib style dependencies in that case (as the port could be installed, but is an older version).
-- Daniel J. Luke
On Jul 24, 2007, at 6:02 PM, Xin Liu wrote:
At least, "install" and "upgrade" should be consistent.
They aren't because they do different things.
If "install" does not install something, "upgrade" should not touch that either;
If you have a solution to the problem (especially a patch) that doesn't cause other problems, then we would be happy to include it in macports, I'm sure.
if "upgrade" would touch something, "install" should install that in the first place. Otherwise, there's too much confusion, and I don't think I'm the only one that is confused.
which is a good reason to not use bin/lib style dependencies.
As for the policy of "including everything in macports", I don't buy it, but it's another story and may be discussed in separate threads.
before you try to re-hash it on the list, perhaps it would be good for you to go through the list archive and read over one of the many times in the past where it has been discussed? -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
exactly ... that's why the use is discouraged ... it only causes problems.
To me it's not discouraged, but simply killed. The end result is that it cannot be used to accommodate external dependencies, and therefore it might be a good idea to completely remove it from the system.
Again, this is a reason why the usage is discouraged. I'm sure we'd be happy to include a patch to fix the issue if it doesn't create other issues as well (as your proposed change would, since it would also incorrectly prevent macports-provided ports from being upgraded if they were installed to satisfy a bin/lib style dependency).
I don't get this part: why would a portfile author use bin style if his package solely depends on something in macports? One possibility is that his package depends on one of two packages that provide the same functionality, and if either one is installed, the dependency is satisfied. However, correct me if I'm wrong, the current port infrastructure does not seem to support such "or" dependency: in a bin style declaration, only one package can be specified if the binary is not present. This pretty much renders bin style useless.
You could just remove the dependency from the portfile, if -n won't work for you and you're insistent on using an external dependency.
Actually that's my solution for gnuplot now. Personally I can live with it; but I just think the macports should be more convenient to use, especially for some users who do not want to understand portfiles.
Indeed, that's why (as I've said a few times now), the bin/lib style dependencies are discouraged in favor of port: style dependencies.
So... in the long run, none of the macport packages should depend on any external programs/libraries? Is this already a consensus? Best Regards, Xin Liu
At least, "install" and "upgrade" should be consistent.
They aren't because they do different things.
A user is simply confused if they are inconsistent. For instance, when the guy invokes "install" for gnuplot (and he has MacTex installed), he is relaxed to find that no extra tex system is installed. However, when later a newer version of gnuplot is available and he invokes "upgrade", he suddenly finds that an additional tex system is installed! Isn't this a bad user experience caused by the inconsistence? At least I didn't feel good, and I reported this as a bug and spent time looking into the source code only to discover that this is a "feature" and I kind of wasted my time. As to the solution for the problem, it really depends on the attitude towards external dependencies. I'd suggest (maybe these are completely wrong, because I haven't read through previous discussions and may miss a lot of points): 1. If ultimately the external dependencies will be removed completely, "install" command should treat bin/lib style dependencies the same way as "upgrade" command, and portfile authors should be advised not to introduce any external dependencies using bin/lib style. 2. If external dependencies are still desirable and will be supported by the system, more explicit dependency styles such as external_bin/external_lib should be introduced, and "update" command should not touch them at all. In either case, I strongly suggest "install" and "upgrade" be consistent. As for the "all-in-macports" philosophy... I don't think I'm persuasive enough to change it :-(, and I'll just maintain my own local port repository to live with it...
Any port that relies on X11 should use bin or lib style dependencies, as Apple's X11 is different than the XFree86 or X.org X11s and all three conflict. Clearly, we do not and should not attempt to install the Apple X11, which, for OS X 10.4 at least, is only available on the OS DVD. Maybe we should write the documentation so that use of bin and lib- style dependencies is only used if there is the possibility that the dependency can be satisfied by a binary or library that is installed as part of Apple system or developer software. On 24 Jul 2007, at 18:18, Xin Liu wrote:
exactly ... that's why the use is discouraged ... it only causes problems.
To me it's not discouraged, but simply killed. The end result is that it cannot be used to accommodate external dependencies, and therefore it might be a good idea to completely remove it from the system.
Again, this is a reason why the usage is discouraged. I'm sure we'd be happy to include a patch to fix the issue if it doesn't create other issues as well (as your proposed change would, since it would also incorrectly prevent macports-provided ports from being upgraded if they were installed to satisfy a bin/lib style dependency).
I don't get this part: why would a portfile author use bin style if his package solely depends on something in macports? One possibility is that his package depends on one of two packages that provide the same functionality, and if either one is installed, the dependency is satisfied. However, correct me if I'm wrong, the current port infrastructure does not seem to support such "or" dependency: in a bin style declaration, only one package can be specified if the binary is not present. This pretty much renders bin style useless.
You could just remove the dependency from the portfile, if -n won't work for you and you're insistent on using an external dependency.
Actually that's my solution for gnuplot now. Personally I can live with it; but I just think the macports should be more convenient to use, especially for some users who do not want to understand portfiles.
Indeed, that's why (as I've said a few times now), the bin/lib style dependencies are discouraged in favor of port: style dependencies.
So... in the long run, none of the macport packages should depend on any external programs/libraries? Is this already a consensus?
Best Regards,
Xin Liu _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
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."
On 7/24/07, Randall Wood <rhwood@mac.com> wrote:
Any port that relies on X11 should use bin or lib style dependencies, as Apple's X11 is different than the XFree86 or X.org X11s and all three conflict. Clearly, we do not and should not attempt to install the Apple X11, which, for OS X 10.4 at least, is only available on the OS DVD.
To me this actually demonstrates the necessity for supporting external dependencies. And is it possible that external tex system be treated the same as Apple stuff? It's really not a good idea to force users use teTeX, which has been officially discontinued.
Maybe we should write the documentation so that use of bin and lib- style dependencies is only used if there is the possibility that the dependency can be satisfied by a binary or library that is installed as part of Apple system or developer software.
I agree. This would make things clear. And a FAQ entry telling average users that "be prepared to install everything from macports; if something happens not to be installed, it's just you are lucky" would be nice. Best Regards, Xin Liu
On Jul 24, 2007, at 7:32 PM, Xin Liu wrote:
A user is simply confused if they are inconsistent. For instance, when the guy invokes "install" for gnuplot (and he has MacTex installed), he is relaxed to find that no extra tex system is installed. However, when later a newer version of gnuplot is available and he invokes "upgrade", he suddenly finds that an additional tex system is installed! Isn't this a bad user experience caused by the inconsistence?
yes, but it can be solved by changing the portfile (and perhaps adding a MacTex portfile?)
At least I didn't feel good, and I reported this as a bug and spent time looking into the source code only to discover that this is a "feature" and I kind of wasted my time.
You didn't waste your time, it's just that your suggested fix causes other problems. If you can think of a better way to do it, I'm sure Macports would be happy to incorporate your changes.
As to the solution for the problem, it really depends on the attitude towards external dependencies. I'd suggest (maybe these are completely wrong, because I haven't read through previous discussions and may miss a lot of points):
1. If ultimately the external dependencies will be removed completely, "install" command should treat bin/lib style dependencies the same way as "upgrade" command, and portfile authors should be advised not to introduce any external dependencies using bin/lib style.
This is the current status. We want to minimize as much as possible external dependencies, so bin/lib style dependencies should generally not be used (unless there's a really good idea to use it). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 7/25/07, Daniel J. Luke <dluke@geeklair.net> wrote:
On Jul 24, 2007, at 7:32 PM, Xin Liu wrote:
A user is simply confused if they are inconsistent. For instance, when the guy invokes "install" for gnuplot (and he has MacTex installed), he is relaxed to find that no extra tex system is installed. However, when later a newer version of gnuplot is available and he invokes "upgrade", he suddenly finds that an additional tex system is installed! Isn't this a bad user experience caused by the inconsistence?
yes, but it can be solved by changing the portfile (and perhaps adding a MacTex portfile?)
The inconsistence between "install" and "upgrade" is an infrastructure problem. Manipulating portfiles is just a temporary hack, and it does not solve the real problem. Fine, we can add a portfile for MacTeX. But the binary is readily available there; how many users are willing to spend the time and CPU compiling it? How about users out there that want to use teTeX? One side will be pissed off, because whenever they upgrade gnuplot, one tex system that they do not like will be forced to install on their systems, and the other tex system cannot co-exist because they simply provide conflicting binaries.
You didn't waste your time, it's just that your suggested fix causes other problems. If you can think of a better way to do it, I'm sure Macports would be happy to incorporate your changes.
I suggest that "upgrade" do not touch bin/lib style dependencies. What problem does this fix cause? You said that this will cause problem for portfiles that use bin/lib style to refer to internal dependencies, but that's their authors' fault: they should not use bin/lib style this way (and I highly suspect any portfile author will do this). Or is there any concrete example that a portfile has to use bin/lib style for internal dependencies?
On Jul 25, 2007, at 12:58 PM, Xin Liu wrote:
You didn't waste your time, it's just that your suggested fix causes other problems. If you can think of a better way to do it, I'm sure Macports would be happy to incorporate your changes.
I suggest that "upgrade" do not touch bin/lib style dependencies. What problem does this fix cause? You said that this will cause problem for portfiles that use bin/lib style to refer to internal dependencies, but that's their authors' fault: they should not use bin/lib style this way (and I highly suspect any portfile author will do this).
All bin/lib dependencies include a port at the end that will fulfill the dependency. If the user doesn't have the external bin/lib, the port gets installed by macports. In the case of upgrade, macports should indeed manage this installed port. There is not syntax for specifying an external dependency without including a port that will fulfill it.
Or is there any concrete example that a portfile has to use bin/lib style for internal dependencies?
all of them? -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
I suggest that "upgrade" do not touch bin/lib style dependencies. What problem does this fix cause? You said that this will cause problem for portfiles that use bin/lib style to refer to internal dependencies, but that's their authors' fault: they should not use bin/lib style this way (and I highly suspect any portfile author will do this).
All bin/lib dependencies include a port at the end that will fulfill the dependency.
I'm aware of the syntax.
If the user doesn't have the external bin/lib, the port gets installed by macports.
How about the user has the EXTERNAL bin/lib? Then the port should not get installed, right?
In the case of upgrade, macports should indeed manage this installed port.
Yes, macports should manage INSTALLED ports. But the port was not installed at the first place, when the user has the EXTERNAL bin/lib at "install" time. Why should "upgrade" install something that was decided to be unnecessary at "install" time?
There is not syntax for specifying an external dependency without including a port that will fulfill it.
The syntax is good.
Or is there any concrete example that a portfile has to use bin/lib style for internal dependencies?
all of them?
I mean, is there any concrete example that a portfile cannot use port style and HAS to use bin/lib style? Best Regards, Xin Liu
participants (4)
-
Daniel J. Luke
-
Randall Wood
-
Ryan Schmidt
-
Xin Liu