On Tue, Oct 20, 2009 at 7:55 AM, Callan Barrett <[email protected]>wrote:
> On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp <[email protected]> > wrote: > > I started aurman project as a simple frontend for AUR, then I realised > 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
