On Wednesday January 21 2015 18:03:45 Lawrence Velázquez wrote: > > 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. > > No, it doesn't. The revision is basically versioning for portfiles and > MacPorts' own fixes. The Infinality patches are more like a supplemental > upstream.
Yes, I know that's what you use and intend(ed) revision for. But think of it this way. If these Infinality patches were my own, I'd do what if I updated them? IIUC, I'd bump the revision. The difference would be that the patches' version would be coupled to the port version, so there wouldn't be the 2-versions issue to resolve. I guess we can have different views of what "corresponding almost perfectly" entails ;) > > 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. > > That sounds like a bug. It would be great if you could open a ticket about it > and provide a minimal test case. I actually considered this approach a rather ugly hack, but apparently it's not unsupported and supposed to work? I'll see if I can come up with one, on the backburner. Meanwhile, I've streamlined the approach with the subport, and I find it more elegant. The whole variant question is pushed a bit to the background: the subport installs an appropriate portion of the extra files, which allows the main port to make +infinality a default variant. I'm not sure though if +infinality will be dropped when you uninstall the subport and rebuild/upgrade freetype? R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
