On Wed, Aug 10, 2011 at 04:25:11PM -0500, Dan McGee wrote:
On Wed, Aug 10, 2011 at 4:21 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Wed, Aug 10, 2011 at 05:02:40PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 10:53:31PM +0200, Lukas Fleischer wrote:
On Wed, Aug 10, 2011 at 04:29:28PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 10:12:44PM +0200, Lukas Fleischer wrote: [...]
RewriteRule ^/packages/([^/]{1,2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
Well, this will kinda fail when requesting "/packages/fo/foo" as it will try to rewrite that. Given that this rewrite rule is used to provide backward compatibility for broken AUR helpers only, I would say that this is ok, though.
Rewriting /packages/fo/foo is bad, always. The anti-backwards compat view would be that not rewriting /packages/fo would be "good". If there's a solution that handles both, I say we go for it. Seems this might be a little difficult though...
Not sure if I understood you correctly, but my "rewrite PKGBUILD/source package" URLs only approach below already does that. It does indeed rewrite everything except for requests trying to "fetch" any of the directories containing the source tarball and the PKGBUILD (given that such a directory doesn't contain anything else).
Then _I_ misunderstood. Carry on.
Maybe we should even ignore everything but PKGBUILDs and source packages:
RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2
Opinions?
-1 from me. Not extensible, but I'll make reference again to aforementioned difficulty in a 'one size fits all' solution.
Any reasons?
Just because maybe in the future we'd have some other file in the package directory that we'd want to make accessible. Do we plan to expire the old URLs at some point (i.e. remove the redirect)? I don't see any real reason to remove them until they cause us pain.
Ack.
Well, as I said before, those rewrite rules do only exist because of some broken AUR handlers (sorry, dude :p ) relying on the current location of the files we currently provide. The next release announcement will contain some notice that hardcoding the source tarball URL is discouraged and unsupported. We might eventually remove the rewrite rules although there is no schedule yet. This is just a favour to all AUR helper developers :)
You're being shortsighted. Bookmarks, old links in emails in both inboxes and archived on mailing lists, etc. are all out there. Don't break something just to break it when it takes one extra rewrite rule line to make sure URLs at least redirect to the right location.
Yeah, I must confess that I wrote that paragraph without thinking twice. Basically, I agree that there's no real reason to remove these rules some day. All I wanted to say here is that AUR helpers shouldn't reply on these rules being enabled forever. And I suspect that some AUR helper developers will do that if we say so in the release announcement (and do not mention that relying on them is unsupported).