port not installed according to registry, yet depends_lib didn't "react"?

[René J.V. Bertin]

On Thursday October 08 2015 12:04:18 Ryan Schmidt wrote:

> I know I've encountered situations where a port failed to build because one of its dependencies was inactive. I'm sure I had forcibly deactivated it at some prior time for some forgotten reason. I don't know why MacPorts wouldn't have reactivated it, but it didn't.

Maybe that has (had) to do with the fact that you can install the newer version of a port, reactivate an older version, and not get bugged by port outdated about it?

> Maybe that kind of thing is what happened to you. The solution is to reactivate the port.

Doubtful: `port installed libical` claimed the port wasn't installed. That shouldn't happen after deactivating a port.

> > Ouch, that's what you get from depending on "internal" software and not on something stable provided by the host :)
> > I sure hope they're working to fix what they broke!
> 
> I have no idea what you're referring to here.

Which part? The fact that portindex apparently uses a python module shipped through MacPorts, and that can be broken by someone who upgrades the module a bit overzealously?

> > Fixing a broken portindex through a port update will be tricky, if the breakage is serious enough, btw.
> 
> I again have no idea what you're talking about.

How are you going to get `port outdated` to consider the fact a port has been updated if portindex is too broken to generate a valid port index?

Anyway, I understand now that it probably wasn't the portindex command that was broken (on every uptodate MacPorts install), but the port index wasn't rebuilt properly because of a syntax error in a Portfile.

I was under the impression that syntax errors were caught and excluded only the affected ports from the index? I'm pretty sure that's how it use(d) to work under 2.3.3 and before, in any case.

R.