On Mon, Feb 6, 2012 at 22:24, Ryan Schmidt <[email protected]> wrote: > What software does that? I have never encountered that situation. In my > experience so far the github tag name is always the version number, in some > cases with a prefix like "v", therefore that is how I modeled the portgroup.
The point is that tags doesn't _have_ to be the version so we shouldn't rely on that. The fact that there's a v is an obvious exception, it could be a "v" like it could be a "bzorp". I understand you do not want to break existing portfiles but port writers should be invited to check if a tag exists or not, taking it from the software version is conceptually wrong, altough it fits majority of cases. > If I'm right that what you've described is extremely uncommon, then I don't > think the portgroup needs to accommodate it; instead, individual portfiles > can override the portgroup's defaults as needed. The whole mechanics seems too much wrapped on most common case. >> Github is offering two kind of package download, and IMHO the github >> portgroup should support both. > As I said above, I don't object to that, but modifications or enhancements to > the portgroup should not break existing ports. I see the point. > Yes, I considered that method too, and it's probably fine. I had not come to > a final decision on what the variable name should be. I wouldn't necessarily > use the word "tarball" in the variable name; if anything, I'd use the word > "distfile" instead. > Possibly, the most MacPorts thing to do would be to have a tbool called > github.use_downloads, defaulting to "no". I'm committing a change that use tarball_from, this is a temporary fix for the ports that currenty doesn't work. I like the use_downloads tbool idea more, but I'll do it later. I checked a few ports (coffee-script among these) and they are correctly fetched. > I'm not sure what other values should change when the author indicates the > desire to use downloads: what about distname? what about livecheck? I had not > yet surveyed enough github ports that use downloads to discover if there was > any usual patterns we could follow, or whether each portfile will have to > define these on its own. Actually the distname is up to the upstream packagin. In this "downloads" are more like a traditional hosting, letting the repository owner to store whatever file, while a "tags" download is automatically packaged from repository and its contents has a root directory different than just the software, it's "author-project-taghash", hence the rename you had to do in post-extract. The distname hasn't even to be in fetch request URI, the path till the tag is enough to http-redirect to the package. Personally I go with downloads whenever possible. **edit: I read your mail about jake while typing this one, when I deleted the version I wasn't realizing that almost all portfiles where relying on version to complete the tag name with the fix I'm committing, again temporary, jake works as well. -- Andrea [1] http://trac.macports.org/changeset/89692 P.S. out of curiosity I was just parading myself because I hadn't received any not from you on my last several commits ;-) _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
