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

Lukas Fleischer archlinux at cryptocrack.de
Thu Aug 11 11:31:08 EDT 2011


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.

Also, I'd like to have equivalent behaviour for Apache and Perl
rewrites. Either this, or we only provide one of them.


More information about the aur-dev mailing list