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 > > > > > <[email protected]> wrote: > > > > > > Signed-off-by: Lukas Fleischer <[email protected]> > > > > > > --- > > > > > > * 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.
