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 <[EMAIL PROTECTED]> 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.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
