[aur-dev] AUR2

[Laszlo Papp]

On Tue, Oct 20, 2009 at 7:55 AM, Callan Barrett <wizzomafizzo at gmail.com>wrote:

> On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp <djszapi at archlinux.us>
> 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