[86151] trunk/dports/audio/liblo/Portfile

[Ryan Schmidt]

On Oct 19, 2011, at 23:46, Jeremy Lavergne wrote:

> Lint doesn't have to be a separate phase though, does it? If you request macports open a connection, and it happens to know it's redirecting, shouldn't it make note of this (as server-side lint)?

I'm not quite sure I follow.

If we open network connections in "port lint", to check for HTTP redirects, that might be unexpected; for example, I expect to be able to run "port lint" when I'm not connected to the Internet.

Thinking outside of the confines of port lint, if we fetch a distfile, and redirects occur, then those redirects are being sent by the distfile web server, a sourceforge server in this case, so we don't have the opportunity to know that on the server side because it's not our server. On the MacPorts client side, we use curl to fetch the distfile and we instruct it to follow redirects. So curl receives any 301 or 302 responses from the server redirecting to other resources, and requests those new resources, all without telling MacPorts. I'm not sure if there's a way to get curl to tell us if redirects occurred. Even if we could, I don't know that it would be appropriate to display that fact in a ui_warn or other message that normal users would see. I think it is appropriate to hide any such information behind "port lint" or another similar command the user would deliberately run (or which the repository server would run and email the result to the committer, like (or included in) the "lint" mails we have now).