[aur-dev] AUR2

[Callan Barrett]

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 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 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