On Mar 1, 2011, at 4:16 PM, Ryan Schmidt wrote: > > The suggestion was: when the version of perl is updated, all ports using the > perl5 portgroup should automatically have their revisions increased. I don't > know how to accomplish that using a portgroup.
Well, you could do it the same way as you would with the epoch (I just think it makes more sense to use epoch). It would still probably require looking at any port that had a revision set already. >>> I think revbumps will have to continue to happen individually in each >>> affected port. >> >> I think it would actually make sense to just set the epoch in the p5 >> portgroup (say to something like YYYYMMDDxx). Then only ports that install >> perl modules that don't use the portgroup would need to be individually >> touched. > > I had not considered using the epoch, and that might work. It presupposes > that no existing port using this portgroup already has an epoch set higher > than this proposed value, but that's not an unreasonable supposition. It also > requires that if a port sets the epoch, it do so before the portgroup, so > that the portgroup can override it. unless you want the portgroup to be able to override the individual ports as well (special magic to set it only if it's greater than the one in the portfile maybe?) > Logically, the epoch has higher precedence than the version, and so should > appear in the portfile on a line above the version, but many existing ports > have their epochs on the line below the version. So we would have to > mass-update epochs to ensure they're before versions, and clearly document > this requirement, and also the requirement that p5 ports would need to use an > epoch of the same format that the portgroup uses. ... but unless we put some code in the portgroup to do special magic, there's still a problem if you ever want to set epoch in the port Without any magic, it only requires looking at any ports that do set epoch on their own (as opposed to rev-bumping or setting epoch on every single port). -- Daniel J. Luke +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
