[aur-dev] [PATCH 1/2] UPGRADING: Mention the upload directory transform script
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- UPGRADING | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/UPGRADING b/UPGRADING index b0185a1..331870e 100644 --- a/UPGRADING +++ b/UPGRADING @@ -19,6 +19,9 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 5. Merge "web/lib/config.inc.php.proto" with "web/lib/config.inc.php". +6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and +rotate the converted directory structure into place. + From 1.8.1 to 1.8.2 ------------------- -- 1.7.6
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- UPGRADING | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/UPGRADING b/UPGRADING index 331870e..4aa05ab 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,17 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place. +7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2 +---- + +If you use a non-standard URL_DIR, slight modifications might be necessary. + From 1.8.1 to 1.8.2 ------------------- -- 1.7.6
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though. UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place. +7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2 +---- + +If you use a non-standard URL_DIR, slight modifications might be necessary. + From 1.8.1 to 1.8.2 ------------------- -- 1.7.6
On Wed, Aug 10, 2011 at 04:27:57PM +0200, Lukas Fleischer wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though.
UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
This can be written as a single rule, courtesy of DJ Mills: RewriteRule ^/packages/([^/]{1,2})(/\1)? /packages/$1/$1 And there's a test script for this: http://paste.xinu.at/9D1/ Disclaimer: I don't know for sure that backrefs are valid in the search pattern. d
+---- + +If you use a non-standard URL_DIR, slight modifications might be necessary. + From 1.8.1 to 1.8.2 -------------------
-- 1.7.6
On Wed, Aug 10, 2011 at 03:29:59PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 04:27:57PM +0200, Lukas Fleischer wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though.
UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
This can be written as a single rule, courtesy of DJ Mills:
RewriteRule ^/packages/([^/]{1,2})(/\1)? /packages/$1/$1
mod_rewrite doesn't work like sed(1). It always replaces the whole URL, not just the part matched by the search pattern. Anyway, good idea to take advantage of greediness. How about this one: 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. Maybe we should even ignore everything but PKGBUILDs and source packages: RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 Opinions?
On Wed, Aug 10, 2011 at 10:12:44PM +0200, Lukas Fleischer wrote:
On Wed, Aug 10, 2011 at 03:29:59PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 04:27:57PM +0200, Lukas Fleischer wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though.
UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
This can be written as a single rule, courtesy of DJ Mills:
RewriteRule ^/packages/([^/]{1,2})(/\1)? /packages/$1/$1
mod_rewrite doesn't work like sed(1). It always replaces the whole URL, not just the part matched by the search pattern. Anyway, good idea to take advantage of greediness. How about this one:
Yeah, I was afraid of that. I'm familiar enough with apache's mod_rewrite, but I don't have a lighty setup to test on.
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...
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. dave
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:
On Wed, Aug 10, 2011 at 03:29:59PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 04:27:57PM +0200, Lukas Fleischer wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though.
UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
This can be written as a single rule, courtesy of DJ Mills:
RewriteRule ^/packages/([^/]{1,2})(/\1)? /packages/$1/$1
mod_rewrite doesn't work like sed(1). It always replaces the whole URL, not just the part matched by the search pattern. Anyway, good idea to take advantage of greediness. How about this one:
Yeah, I was afraid of that. I'm familiar enough with apache's mod_rewrite, but I don't have a lighty setup to test on.
Mh. Now that you mention it - we should probably add some lighty instructions here as well (primarily since we're running a lighttpd setup on sigurd).
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).
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?
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:
On Wed, Aug 10, 2011 at 03:29:59PM -0400, Dave Reisner wrote:
On Wed, Aug 10, 2011 at 04:27:57PM +0200, Lukas Fleischer wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- Forgot to consider package names with length 1 here. We could probably also merge both RewriteRules. The resulting rule might be quite confusing, though.
UPGRADING | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..fd10707 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,18 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. If you want to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule /packages/([^/])(/[^/]*)?$ /packages/$1/$1$2 +RewriteRule /packages/([^/]{2})([^/]*(/[^/]*)?)$ /packages/$1/$1$2
This can be written as a single rule, courtesy of DJ Mills:
RewriteRule ^/packages/([^/]{1,2})(/\1)? /packages/$1/$1
mod_rewrite doesn't work like sed(1). It always replaces the whole URL, not just the part matched by the search pattern. Anyway, good idea to take advantage of greediness. How about this one:
Yeah, I was afraid of that. I'm familiar enough with apache's mod_rewrite, but I don't have a lighty setup to test on.
Mh. Now that you mention it - we should probably add some lighty instructions here as well (primarily since we're running a lighttpd setup on sigurd).
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)? dave
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)?
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 :)
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.
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. -Dan
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).
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule. UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place. +7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +---- + +If you use a non-standard URL_DIR, slight modifications might be necessary. + From 1.8.1 to 1.8.2 ------------------- -- 1.7.6
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions? Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does. -Dan
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
On Thu, Aug 11, 2011 at 03:46:51PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
So, this still seems crazy to me. The solution I proposed works and uses a singular regex which conforms to lighty specifications as far as I can tell. We gain backwards compat, and nothing at all breaks. Referencing lighty's doc... http://redmine.lighttpd.net/wiki/1/FrequentlyAskedQuestions This makes reference to: http://www.regular-expressions.info/brackets.html Which clearly shows a backref being used in the match space. The fact that I used an _equivalent_ pattern in sed was for purely for testing purposes to prove that the pattern does what I want it to. Do you know for sure that implementing this rule as I proposed it in lighty syntax does not work? dave
On Thu, Aug 11, 2011 at 10:47:24AM -0400, Dave Reisner wrote:
On Thu, Aug 11, 2011 at 03:46:51PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
So, this still seems crazy to me. The solution I proposed works and uses a singular regex which conforms to lighty specifications as far as I can tell. We gain backwards compat, and nothing at all breaks.
Referencing lighty's doc...
http://redmine.lighttpd.net/wiki/1/FrequentlyAskedQuestions
This makes reference to:
http://www.regular-expressions.info/brackets.html
Which clearly shows a backref being used in the match space. The fact that I used an _equivalent_ pattern in sed was for purely for testing purposes to prove that the pattern does what I want it to. Do you know for sure that implementing this rule as I proposed it in lighty syntax does not work?
That doesn't fix the aforementioned issue. Again, this _cannot_ be implemented properly due to the nature of our new directory structure. To give an example, your regular expression will fail to rewrite "/packages/st/st.tar.gz" properly (which even exists in AUR and is not purely hypothetical at all) as it will assume that the URL is already rewritten. If you still don't believe me, please read my last reply in this thread again carefully. Also, I'd like to have equivalent behaviour for Apache and Perl rewrites. Either this, or we only provide one of them.
On Thu, Aug 11, 2011 at 05:31:08PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 10:47:24AM -0400, Dave Reisner wrote:
On Thu, Aug 11, 2011 at 03:46:51PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
So, this still seems crazy to me. The solution I proposed works and uses a singular regex which conforms to lighty specifications as far as I can tell. We gain backwards compat, and nothing at all breaks.
Referencing lighty's doc...
http://redmine.lighttpd.net/wiki/1/FrequentlyAskedQuestions
This makes reference to:
http://www.regular-expressions.info/brackets.html
Which clearly shows a backref being used in the match space. The fact that I used an _equivalent_ pattern in sed was for purely for testing purposes to prove that the pattern does what I want it to. Do you know for sure that implementing this rule as I proposed it in lighty syntax does not work?
That doesn't fix the aforementioned issue. Again, this _cannot_ be implemented properly due to the nature of our new directory structure. To give an example, your regular expression will fail to rewrite "/packages/st/st.tar.gz" properly (which even exists in AUR and is not purely hypothetical at all) as it will assume that the URL is already rewritten. If you still don't believe me, please read my last reply in this thread again carefully.
Sure, and now that you've actually provided a reason that it doesn't work, we can write a better test and figure out a better solution.
Also, I'd like to have equivalent behaviour for Apache and Perl rewrites. Either this, or we only provide one of them.
Separate issue... d
On Thu, Aug 11, 2011 at 11:46:24AM -0400, Dave Reisner wrote:
On Thu, Aug 11, 2011 at 05:31:08PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 10:47:24AM -0400, Dave Reisner wrote:
On Thu, Aug 11, 2011 at 03:46:51PM +0200, Lukas Fleischer wrote:
On Thu, Aug 11, 2011 at 08:11:25AM -0500, Dan McGee wrote:
On Thu, Aug 11, 2011 at 7:46 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- * Rules rewritten using a single regular expression. * Added an equivalent lighttpd rewrite rule.
UPGRADING | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/UPGRADING b/UPGRADING index 331870e..aff780f 100644 --- a/UPGRADING +++ b/UPGRADING @@ -22,6 +22,23 @@ ALTER TABLE PackageDepends ADD INDEX (DepName); 6. Run the upload directory transform script ("scripts/uploadbuckets.sh") and rotate the converted directory structure into place.
+7. In order to to provide backward compatible package URLs, enable mod_rewrite +and add the following to your Apache configuration (inside the "VirtualHost" +container or optionally create a ".htaccess" file in the upload directory): + +---- +RewriteEngine on +RewriteRule ^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$ /packages/$1/$1$2 +---- + +The following equivalent rule can be used for lighttpd setups: + +---- +url.rewrite-once = ( "^/packages/([^/]{1,2})([^/]*/(PKGBUILD|.*\.tar\.gz))$" => "/packages/$1/$1$2" ) +----
I'm still -1 on this. I don't think we need to assume the contents of these directories in a rewrite rule, nor do I think it makes the rules any clearer. Can we please just use rules that don't make assumptions?
We need to make assumptions here. If we don't, there's no way to determine whether a client tries to fetch the file "foo" from the upload directory of package "fo" or the package upload directory of "foo" when requesting "/packages/fo/foo". Of course, we could check for existence of both files in that case and just use "/packages/fo/foo" if both of them exist, but this is even more unpredictable and difficult to implement. Keep in mind that this is a backward compatibility measure only.
Does this even let me go to http://aur.archlinux.org/packages/gephi/ correctly? I don't think it does.
No. I don't think that we do officially support directory listing, thought. And as I pointed out before, this is impossible to implement.
So, this still seems crazy to me. The solution I proposed works and uses a singular regex which conforms to lighty specifications as far as I can tell. We gain backwards compat, and nothing at all breaks.
Referencing lighty's doc...
http://redmine.lighttpd.net/wiki/1/FrequentlyAskedQuestions
This makes reference to:
http://www.regular-expressions.info/brackets.html
Which clearly shows a backref being used in the match space. The fact that I used an _equivalent_ pattern in sed was for purely for testing purposes to prove that the pattern does what I want it to. Do you know for sure that implementing this rule as I proposed it in lighty syntax does not work?
That doesn't fix the aforementioned issue. Again, this _cannot_ be implemented properly due to the nature of our new directory structure. To give an example, your regular expression will fail to rewrite "/packages/st/st.tar.gz" properly (which even exists in AUR and is not purely hypothetical at all) as it will assume that the URL is already rewritten. If you still don't believe me, please read my last reply in this thread again carefully.
Sure, and now that you've actually provided a reason that it doesn't work, we can write a better test and figure out a better solution.
No, we can't do that without assuming the contents of the directories (which is the best thing we can do). *Please*, read my last reply to Dan in this thread if you're interested in any reasons. It's not that I'm too lazy to figure out a proper solution. Such a solution doesn't exist.
participants (3)
-
Dan McGee
-
Dave Reisner
-
Lukas Fleischer