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.

On 03/08/10 19:14, ludovic coues wrote:

I don't understand what you will be able to do for pacman with AUR. ABS isn't a best place to check PKGBUILD ?

At the risk of sounding rude, I'm gonna come right out and say that none of that made any sense.

On 03/08/10 20:54, Xyne wrote:

On Tue, 03 Aug 2010 19:29:01 +0100 Nathan Wayde wrote:

...

On 03/08/10 19:14, ludovic coues wrote:

...

I don't understand what you will be able to do for pacman with AUR. ABS isn't a best place to check PKGBUILD ?

At the risk of sounding rude, I'm gonna come right out and say that none of that made any sense.

I think he was suggesting that you collect the PKGBUILDs and local source files from the ABS tree (which you can download via rsync using the "abs" package) and use those in place of the AUR PKGBUILDs for testing purposed.

In that case I'm no better off than I would have otherwise been as I have exactly that info from the pacman db files already.