On Jan 21, 2015, at 3:03 PM, Lawrence Velázquez <[email protected]> wrote:
> On Jan 21, 2015, at 5:10 PM, René J.V. Bertin <[email protected]> wrote: > >> 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. > > Sure. > >> 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. > >> 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 wonder if port livecheck considers installed variants? Regards, Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
