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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
