On Tue, Oct 20, 2009 at 1:05 PM, Sebastian Nowicki <seb...@gmail.com> wrote:
> 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. > > Hello Sebastian! Yeah, as I told my final purpose a command-line that arch users like, you can see it from the important application, like pacman, aif (arch installer project), devtools, dbscripts, pkgtools, etc.. Arch is a minimal based distribution, but I know you know it hehe :) Nevertheless I don't see any reason for it to be web application, but of course I won't touch web application, so it will be available too, and the users will choose. > 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. > > Yeah, 'aurman' has other goals than 'AUR2', but yeah you're right with it, any web application and gui frontend will be able to use aurman's api, backend, I will do it in that way, at least I try. > 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. > > No-no, I won't fork it absolutely, just reuse some useful functions from it that's written, but obviously not all of them even you can see so much source codes from that, I will refactor so much things in the future, as I said it's not a simple work for an afternoon, but I fight with it :) Well, my API library will be named 'libalam', which mean Arch Linux Aur Manager, similar like libalpm, Arch Linux Pacman Manager. I think it's a good name choice for it to keep arch related projects closed together, not absolutely different way. Summary: It will be two different API. > 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. > The webserver is a good choice for package storing as http/ftp two, as you see it in case of archlinux mirror too, okay no problem for me to build a web front end for aurman API or similar, but that I'd like to establish is a command line tools as much as possible. What do you think about this small PKGINFO modification? http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz Thanks the feedback really Sebastian, maybe we will change idea more in the future about I think, maybe we will collaborate, hehe. Best Regards, Laszlo Papp