[aur-dev] AUR2

[Sebastian Nowicki]

On Oct 19, 2009, at 9:52 PM, Laszlo Papp wrote:

> I think AUR2 would be just a temporary solution for our final  
> purposes. I
> started to plan/design quite a few weeks ago the new AUR generation  
> with
> Louipc, and we think of an absolutely new implementation/idea. We  
> would like
> for AUR to be a command-line based application like pacman. Well,  
> I'd like
> to see a more robust, and efficient impelementation of it, not a web  
> based
> application.

It depends what these "final purposes" are. The web frontend I am  
developing is exactly that, a web frontend. It works in exactly the  
same way as the package catalogue on the main site. Just because  
there's a web frontend doesn't mean that "third party" clients can't  
communicate with the server. After all, pacman does.

It is this separation of functionality that allows the server, web  
frontend and command line or GUI clients to co-exist. There's no  
"temporary solution", your project simply has other goals. If you  
don't like the idea of a web frontend, simply forget about it. Even if  
you make a server, api and client, I will still be able to make a web  
frontend that utilizes that.

On Oct 20, 2009, at 6:17 AM, Laszlo Papp wrote:
> 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.
>
> 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.
>
> Sorry for my relatively long post :)
>
> Best Regards,
> Laszlo Papp

I think it would help if we actually knew what this client was meant  
to do. It seems to me like there's a _lot_ of feature creep. I don't  
understand why you forked the pacman source code (including libalpm).  
The whole point of libalpm is to have a common library which handles  
database manipulation and package reading. Why fork it instead of  
simply linking against it? If the libalpm code differs, I doubt that  
people would want to use your client, for fear of breaking their  
database.

I'd also like to know specifically what the server would do. I really  
can't think of a reason not to use a mature and efficient web server  
who's specific purpose is to serve files. Considering that a web  
server is perfect for this purpose, I also don't understand why you're  
so opposed to a web frontend. It only seems logical. The two do not  
have to be tightly coupled.