[aur-dev] AUR2

[Laszlo Papp]

On Tue, Oct 20, 2009 at 1:05 PM, Sebastian Nowicki <sebnow at 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