[aur-dev] Can I please get a dump of the pkgbuilds in AUR?

[Nathan Wayde]

On 01/08/10 18:38, Loui Chang wrote:
>
> I recommend helping improve the AUR's search functionality then.

If research proves successful and time permits then I'll happily look 
into incorporating some of my ideas into the web-search but for now: not 
gonna happen.

> I cannot see any practical reason for you to have all the files in the
> AUR. Do you want to do some kind of analysis or something?
>

pretty much, I'm researching? ideas I've had about improving the 
interface to tools I use every day, call it HCI if you will.

> It would be nice if you could share your intentions if you expect to
> receive data in your preferred format. Otherwise all the files are
> freely accessible via other methods.
>

What are these other methods apart from hammering the server through 
scraping?

> That said, I still need a really compelling reason to do this. It would
> probably be better to explore other ways to solve your problem.
>
>

Ok, I'll shed some light on the situation. I've been using Arch for 
years now and I like pacman, it's simple to use and to the point but 
it's SLOW!!

When syncing I can appreciate the fact that it's slow at calculating 
dependencies etc. mostly due to disk activity but that's different as 
that activity isn't very interactive: I start it and it's mostly 
automatic from them on.

The problem is in searching, it's too slow. If I search for something 
then it should give me feedback *immediately* if it takes 1 second then 
it means I'll notice it and that's annoying. Fine, I'll index the data 
myself so I get fast search, speed problem solved.

Now comes the bigger problem, usability. The biggest annoyance with 
pacman is its lack of recoverability, if I specify a long list of 
packages to install then I must wait for it to do its thing and then 
*crash* because I missed a letter in one of the package names.

Fine, in my tool I'll add a feature whereby every query that may fail 
but is recoverable goes through another layer in which the routine 
doesn't return upon failure, instead it prompts the user with helpful 
hints. e.g If the activity is a package install, it first verifies 
existence of all the package names, if it finds that one is missing then 
it suggests possible alternatives, like similar package names or other 
related packages or to re-sync the db and try again.

Great, problem solved, until we get to the AUR. I have no data so I 
can't incorporate any of it. It's hard to use the AUR because the 
PKGBUILD descriptions for the most part are almost useless and to add to 
that if I search from the AUR rpc then I get what I get, I'm limited by 
the AUR search facilities which isn't very useful unless you know the 
package names in advance or are willing to wade through a list of cruft 
to try and find what you might be looking for and even that requires 
that you know the package name in advance in most cases.

Solve that issue and we're still limited by our network speed which 
means for most? of us we must wait for search results which I already 
mentioned in pacman's case is annoying, especially when the results 
aren't going to be that great.