About adding a version component: the case of Infinality (was depends_run should ignore +/- universal?!)

[Ryan Schmidt]

On Jan 23, 2015, at 4:48 AM, René J.V. Bertin wrote:

> On Thursday January 22 2015 21:45:09 Ryan Schmidt wrote:
> 
>> I don't think we ever intended the version to be changed inside a variant. I would consider it a maintainer error to do so. I don't think the portindex accommodates more than one version per port, and the portindex is used to determine what ports are outdated.
> 
> I haven't yet checked how that plays out exactly, but I think I did see that livecheck considered that `1.14.0.20150101` was older than `1.14.0`, which surprised me. Maybe the additional version component should piggyback the revision mechanism and use an underscore as the separator, I should test that.
> Is it more acceptable to bump the port revision in a variant, say the Tcl equivalent of `revision+=infinality_version` ? I know that strictly speaking a mod to a variant is also a mod to the whole portfile, but it seems useless to force everyone to rebuild a port when there's a change only to a variant.
> 
> The thing is that MacPorts doesn't seem to have a straightforward or even appropriate mechanism to introduce a dependency on an independent upstream contribution that doesn't take the form of plugin(s) or other stuff that can be installed and referenced at runtime. In my case, they're bohoomil's Infinality patches to the ports' (freetype, fontconfig and cairo) source code. In fact, that's not correct: an appropriate mechanism exists that provides all the required functionality, but it's not intended to be used accordingly (the port revision). Included in that required functionality is of course support for causing a rebuild when the Infinality is updated.
> To make things worse, I even have to track 2 versions of those patches, because I'd like to shy away from bumping freetype to v 2.5.5 which is what the latest Infinality patches target. Conveniently, I'm writing this in reply to a message from that port's maintainer ;)
> But suppose I could track only a single Infinality version and create a single port that could exist to provide everything required to build freetype, fontconfig and cairo with the +Infinality variant. The fact would remain that there is no logical place to install patches, or to add them to the ports' patchfiles lists (none of which are empty for the default variants) without copying them into ${filespath}. Would that be acceptable behaviour?
> 
> A bit more detailed information might help if someone is interested in helping me come up with an appropriate solution. Bohoomil's fontconfig-ultimate (aka "Infinality Ultimate") project in fact contains
> 
> -1 Freetype modifications: patches, and a settings file that controls how freetype uses its modified rendering engine. The patches are maintained and thus change regularly (usually including upstream fixes to freetype); the settings file from time to time. To stop hijacking the port revision, I created a freetype-infinality subport that stores the settings files under ${prefix}/share/fonts, where the main port's +infinality variant will reference it. The user has to manhandle at least one of these files anyway; 2 are alternative profiles for [ba]sh, the other is a version for csh I provide.
> 
> -2 Patches to fontconfig, and a big database of rendering instructions for individual fonts. The patches rarely change, but the config files often, and they are of course meant to be installed somewhere under ${prefix}. Same as with freetype, I settled on a fontconfig-ultimate (sic) subport that (in this case) grabs the tarball from bohoomil's server, and installs the config files under ${prefix}/share/fonts/fontconfig-ultimate. IIRC (I'm not at the Mac) it doesn't use the patches included in the download; those are in ${filespath} as usual, esp. since one of the patches overlaps with an already provided patch (but only partly).
> 
> -3 Patches to cairo. Those do include upstream fixes cherry-picked from cairo/git but the actual infinality related patches rarely change. This is the component that's least suitable for becoming a (sub)port so for now I've settled on changing the port version in the +infinality variant.
> 
> I'll upload the current Portfile drafts to the existing infinality tickets on trac when I get back to my Mac so it'll be easier to give feedback grounded in actual code rather than a brief description. But reading that description, I think that a single Infinality port as hinted at above doesn't really make sense, given how the 3 components evolve at a different rythm. In fact, what evolves most are the font config files, and those don't require a port rebuild at all. The fontconfig +infinality variant could thus have a runtime dependency on fontconfig-ultimate only, at least as long as the corresponding patches are shipped with the port and not grabbed from a download.
> NB: I prefer to use the +infinality variant throughout for consistency and to indicate what it actually does; the font config files are just a (thick, savoury) icing on the cake.

You're right, MacPorts doesn't have a good way to handle third-party patches that are independently maintained and independently versioned. I've been avoiding this ticket of yours, because I don't like such patches. The developer of the patches should submit them to the developers of the projects being patched, for inclusion in those projects, so that then no patches would be needed.