Re: [aur-dev] AUR2

On Tue, Oct 20, 2009 at 7:55 AM, Callan Barrett wrote:

...

I started aurman project as a simple frontend for AUR, then I realised

On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp wrote: the

...

new idea later for it to be able to be a backend, api, frontend too.

I see where you're coming from but I still think you should start at the backend.

I'm working on the backend, api now.

...

I needn't to rewrite everything in the client, because I tried/try to write the code in portable way, just see the json api interface, It's available from C too, with the same output that the frondend parses(I maintain the jsonapi-c in AUR too). You could see from me patch with json-interface related thingds, because of this. Tell the truth mysql api in C is good enough to get the data from the AUR database, and giving back json interface related output. Summary: it's absolutely not a wasted work, nevertheless I got some internal operations from AUR, and it's cool to get such an experience too :)

It's just that the JSON interface is likely to change in an overhaul and if your application is written correctly interfacing with the AUR this way should be the biggest part of it. I'm not sure I get how this is work not lost.

I've never said it's a small work with few C source lines so I agree with you in this regard, but my implementations until now it's useful and will be used, so it's not a big work losing, I just need to conitnue with the api, backend implementation and I'm working on it.

...

I use pacman codebase as a sample, because I dealt with it in the past to understand, and I think it's a good project as a starting point, I admire pacman-project :P And it's better to understand two similar codebase than understanding two absolutely different codebase, I think so.

I don't understand how they're similiar either. As far as I'm concerned this is how an AUR command line utility should work: if you tell it to get a certain package it would get that, *MAYBE* run makepkg as some sort of wrapper and *MAYBE* run pacman as a wrapper to install it. Nowhere in that process should the aur tool touch the produced package or manage any sort of database of packages which is what I thought the entire point of libalpm was.

...

It won't be a pacman wrapper, if you think of that, however I established for it with command-line options to wrapper pacman and makepkg applications. But to tell truth here too, I'd like if it was just optional dependency of aurman. I don't like third party tools and applications as a dependency, so I avoid them as I can, so I don't say with it pacman or makepkg is a bad program or something similar, just that I'd like to be as independent as I can. I won't be full independent from pacman/makepkg because of PKGBUILD, PKGINFO files e.g. I linked the above suggestions above to give idea/suggestion/recommandation.

Having third party dependencies is unavoidable when you're creating a tool that just manages skeleton files for building packages. If you want to automate the process of building and installing packages you've really got no choice but to act as a wrapper to the proper tools for this job, not roll your own version of everything. If you do this the project will never be official and probably will be impossible to maintain considering you're duplicating the efforts of both the pacman and makepkg team plus your own work.

-- Callan Barrett

Hm, yeah Callan, I need to say I agree with you here too, so current implementation with pacman, makepkg wrapper facility may remain, and needed some extension for it. I don't know in fact 'aurman' and similar application can ever be official supproted, I don't know exactly the arch policy in this way. Thanks your feedback :) Best Regards, Laszlo Papp