depends_run should ignore +/- universal?!

René J.V. Bertin rjvbertin at gmail.com
Wed Jan 21 14:10:12 PST 2015


On Wednesday January 21 2015 14:16:38 Lawrence Velázquez wrote:


> > The freetype +infinality variant will have a runtime dependency freetype-infinality, a (sub)port that serves mostly to introduce the versioning information for the Infinality patches, but also installs a few text files.
> 
> This sounds pointlessly complex. Why not have ONLY a variant or ONLY a subport (which would conflict with freetype, I suppose)?

The situation is this: Infinality are patches that improve rendering but don't change anything else. So a variant is the logical way to go, as it won't break dependencies. Those patches evolve, and thus have a version number, which is simply a date. If it were me, I'd put that version number into the revision, which corresponds almost perfectly to the intended use of that variable. Updated patches mean I have to update the portfile, while the targeted freetype version remains the same. The only "not-done" aspect is that you end up with a revision that's not a small integer.

I've tried changing the version in the +infinality variant, so that for instance port:freetype is at 2.5.4 and port:freetype+infinality at 2.5.4.150101 . That works, but something in MacPorts breaks. I can do  `port patch freetype +infinality` to check whether the patches apply correctly, but when I continue with `port configure freetype +infinality` the process continues all the way to the install or until the 1st error.

So my approach with the subport was an attempt to remain within legal boundaries and yet have a sensible way of tracking the Infinality patches version. Using a subport may even make it easier to trigger a freetype rebuild when the patches have been updated.

> 
> > It is thus pointless to distinguish between universal and non-universal for that subport, because of its nature and because of the kind of dependency.
> 
> You're not thinking about this correctly. What you want to do is set `supported_archs noarch`.

I just didn't know about that keyword...


More information about the macports-dev mailing list