portfile question concerning optional deps

[Ryan Schmidt]

On Mar 3, 2011, at 16:58, Daniel J. Luke wrote:

> On Mar 3, 2011, at 5:54 PM, Ryan Schmidt wrote:
>> 
> 
>> That would be the opposite of the way that these works today, and I can't imagine wanting to go through all thousands of ports and switch this.
> 
> If it makes things better, it's worth it.
> 
> Most ports only use port: style dependencies any way...
> 
> I don't think it would be an extreme effort to change things (I'll even volunteer to do it in a couple of months when I can spend some extra time on this).

Yes, most ports use port:-style dependencies, because that's all they need; when special needs arise, other types can be used.

I still don't see why you think changing how the dependency styles work makes anything better.

How, in your new proposal, would someone indicate that a binary anywhere in bin_path should be acceptable? (what bin:-style currently does)

How would someone indicate that only a particular file in ${prefix} is acceptable? (what path:-style currently does)

What would it be possible to specify in your new dependency style that we can't already accomplish with what we have today?


>> I would rather educate port authors as to how to use them the way they work today, and improve the documentation if needed.
> 
> There's basically no documentation (the guide doesn't mention it, and the Portfile man page doesn't either).

It is documented in the guide; the wording and arrangement could possible be improved:

http://trac.macports.org/browser/trunk/doc-new/guide/xml/portfile-dependencies.xml#L109

Also, that section does not appear on the guide web site:

http://guide.macports.org/

In its place, there appears just "<xi:include></xi:include>" (scroll up just a little from http://guide.macports.org/#reference.variants to see that). I do not know why. It used to show up fine. Maybe there is a syntax error in the XML somewhere, or maybe the guide just needs to be regenerated.


>> path:-style doesn't search $PATH; it looks for a file at a particular path specified in the dependency, i.e. path:/usr/bin/grep:grep or path:${prefix}/bin/grep:grep. If the path is not absolute, "${prefix}/" is prepended to it.
>> 
>> bin:-style searches bin_path.
>> 
>> lib:-style does something similar for libraries.
> 
> And this behavior is totally obvious?

I don't say it's obvious, I say it's how it works, and has worked for years, and we should document that in a way that everyone can understand that.


> (I know you changed a bunch of your ports a while back because you didn't realize it works this way - and you're probably more informed than most port maintainers...)

I don't recall... but if that's true, then I'm glad someone educated me on how things actually work. :) I do remember not realizing that "${prefix}/" could be omitted from path:-style dependencies; maybe that's what you meant. And at that time we also discovered there was a bug with the handling of path:-style dependencies, which was then fixed.

If we go changing the way things work again, we're bound to introduce new bugs, just when everything is actually working as designed, so let's not.

Also, coordinating changes in base with changes in portfiles is a hassle since we don't have a way to ensure that users upgrade base at any particular time. Users often sync to get new portfiles, and don't necessarily selfupdate to get new base as often. It's bad enough when we add a new feature to base and then want to use that new feature in portfiles; we have to wait weeks after the release before we touch the portfiles to increase the likelihood that most users will have upgraded base by then, and even so we still get reports from those who haven't. It would be a nightmare if we *changed* how *existing* functionality behaves.