[aur-dev] AUR2

Ryan Coyner rcoyner at gmail.com
Sat Oct 24 16:25:35 EDT 2009

On Tue, Oct 20, 2009 at 4:51 PM, Laszlo Papp <djszapi at archlinux.us> wrote:

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


I've been chatting with Laszlo for a bit. It's very refreshing to see some
enthusiasm on the subject of AUR2 again. I've been working on the Lex/Yacc
parser for the PKGBUILD but it hasn't been touched since May because of a
number of reasons, but this thread has helped spark my interest again.
Before we start doing some serious coding though, we really need to take a
step back and go back to the drawing board.

>From reading this thread, we can break down what we want to accomplish into
3 separate components:

Client - (Web/CLI Frontend)
Server - (Repository)

Obviously each component will have its own sub-modules. Let's not get these
core components mixed up though. We first need to completely nail the
specifications of the data and the structure of a source-package
(non-binary). That means comments on Loui's RFC and overall brainstorming of
what consists of a source-package. My comments on the RFC and metadata

1) I like the direction of the proposed PKGINFO. I don't know if the
pkgbase/pkgname mechanism is the right answer, but making dependencies an
attribute of the architecture makes a lot of sense.

2) Why aren't we using a markup language like XML or JSON?  It would make
parsing really easy, and making clients would be a lot easier. As for the
build() function... can't we just use Makefiles? That's essentially what it
is. There was actually a thread on the forums about this.

3) Right now there's a redundancy in how package metadata is treated. If you
look at /var/lib/pacman (which deals with binary packages), it splits up the
metadata in depends/desc/files/install, etc. If you look at the ABS (deals
with source packages), it splits up the metadata in PKGBUILDs and PKGINFOs.
Why not just use one or the other?

More on this topic later. Cheers.

Ryan Coyner [http://ryancoyner.com]

More information about the aur-dev mailing list