On Mar 3, 2011, at 20:08, Daniel J. Luke wrote:
> On Mar 3, 2011, at 6:26 PM, Ryan Schmidt wrote:
>>
>
>> How, in your new proposal, would someone indicate that a binary anywhere in
>> bin_path should be acceptable? (what bin:-style currently does)
>
> path:foo
>
> would search for foo in binpath
>
>> How would someone indicate that only a particular file in ${prefix} is
>> acceptable? (what path:-style currently does)
>
> path:${prefix}/foo
>
> any absolute path would just check for that exact file
>
>> What would it be possible to specify in your new dependency style that we
>> can't already accomplish with what we have today?
>
> Port A depends on specific library B (and not just on the port that provides
> B).
Already possible:
path:lib/libB.dylib:B
> Or port A depends on specific binary Q (and not just on the port that
> provides Q).
Already possible:
path:bin/Q:Q
>>>> 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/
>
> ... which means it's not really in the guide (at least right now).
>
>> 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.
>
> Good to know it's probably just something simple that can be 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.
>
> Ok, so we're in permanent code freeze? Everything is perfect now. ;-)
Obviously not. There are many things broken in MacPorts that need fixing. There
are even things about dependencies that need fixing or redesigning. I'm just
not seeing why the aspects you're concerned with in this thread fall in that
category.
>> 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.
>
> So we need to implement some better handing for that kind of upgrade, then,
> right?
>
> We could implement the same idea without re-using the existing lib/bin/path
> stuff, too (if that would make it easier). The more-specific dependency types
> would just be new names.
Yes, that would make it easier.
> ... or if we automate link checking, then I don't really care (we can
> discover any library/link dependencies and record them - any other dependency
> would be a 'file' dependency [header, executable, or other data]).
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
