On Mar 1, 2011, at 14:13, Daniel J. Luke wrote: > On Mar 1, 2011, at 2:28 PM, Ryan Schmidt wrote: >> > >> On Feb 28, 2011, at 20:33, Arno Hautala wrote: >> >>> This would also be a good candidate for enhancing the perl5 PortGroup. >>> Automatically "revbump" when the perl5 port is updated. Though this >>> could probably be rolled into the version dependency work. >> >> The portgroup isn't the appropriate place to do that. > > Why not? > >> I'm not even sure code to do what you're suggesting is possible in a >> portgroup. > > Why not? > > Looks like portindex uses mportopen. I haven't tested it (yet), but a cursory > look at the source seems to indicate that it should work. > > The group file is basically just included into the portfile anyway.
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. Yes, the portgroup is included into the portfile, but at the very top, before anything else in the port has been executed. Then a few lines further down, the port calls the perl5.setup procedure, passing it the name and version of the perl module. Then the port might define a revision, if there is one. By the time the port defines a revision, if any, there are no more calls to the portgroup, thus no chance for it to modify the revision. And even if there would be a way for it to, say, increment the revision that's already in the portfile, that would be pretty confusing, wouldn't it? The portfile says version 1.0 revision 1 but in fact version 1.0 revision 2 gets installed. If the maintainer increases the revision in the portfile to 3, revision 4 actually gets installed. Nobody would expect that. And would such code just stay in the portgroup stay there forever? I don't see how it could ever be removed. But I can stop thinking about that idea because you proposed a different one: >> 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. 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. (I never really liked seeing the epoch as a date/timestamp because I didn't see any purpose to it, and was going to change the Guide to recommend simple incrementing integers, like we use for the revision and like many ports use f or the epoch, but this suggestion for the perl ports does look like a good use of that.) _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
