[aur-dev] [PATCH v3] UPGRADING: Add note on backward compatible package URLs

[Dave Reisner]

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 at cryptocrack.de> wrote:
> > > > > Signed-off-by: Lukas Fleischer <archlinux at 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