[aur-dev] AUR2

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

Boys,

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)
Data - (PKGBUILD)
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
structuring:

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?