On 10/19/2009 04:40 AM, Sebastian Nowicki wrote:

On Oct 19, 2009, at 8:38 AM, Dave wrote:

...

Hi all,

I came across a forum post (http://bbs.archlinux.org/viewtopic.php?id=80997) discussing how AUR needs to be improved, which led to the AUR2 wiki page. However, the last major updates, either to the Wiki page or the git repository, happened in February. I was wondering what the status of the project was and, if the project is still alive, contribute by coding and updating the Wiki . If the project is not alive, I would like to know why and if it would be worth bring the discussion back up.

AUR2 stagnated because I no longer have the time to work on it, and there doesn't seem to be enough interest for it for others to contribute. The project has come quite a long way and the basics of the AUR have been replicated. I think the todo list on the wiki is still fairly up to date. Back in February I was re-writing the package upload logic to be better designed and use parched[1] instead of using bash directly (it's insecure). Unfortunately my disk died and the pkgbuild branch[2] might not have all my work. I also wrote more of the API handling stuff but that's all gone now :(.

I'm not really sure whether AUR2 would be official supported and, if it were finished, if it would be integrated to http://aur.archlinux.org. I do recall interest in it though, but it should be discussed further.

I would still like to work on the project and see it finished, I simply don't have the time to do so. If anyone else would like to work on it, I'm more than happy to help in any way.

P.S. Thanks for linking to that thread, seems someone else is working on a proper parser, yay!

[1] http://github.com/sebnow/parched [2] http://github.com/sebnow/aur2/tree/pkgbuild

Hmmm, dying project with little to no official support? Count me in! Would you recommend that your repository be the main repository? I'm not quite sure what the status of the "central" repository is at this point and you can't even connect to Thralas' repository. I'm rushing off to work right now, but I'd like to start updating the Wiki this week and then digging into the source code by the weekend.

On Mon, Oct 19, 2009 at 4:05 PM, Sebastian Nowicki wrote:

On Oct 19, 2009, at 4:40 PM, Dave wrote:

...

Hmmm, dying project with little to no official support? Count me in! Would you recommend that your repository be the main repository?

I suppose so. It's the most up-to-date repository. I'm pretty much the only dev anyway :P.

I'm not quite sure what the status of the "central" repository is at this

...

point and you can't even connect to Thralas' repository.

I haven't updated the "central" one in ages. I guess I should delete as it probably won't get any use anyway.

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. We started to redesign PKGINFO related things: http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz You can see here the state of it here: http://git.berlios.de/cgi-bin/gitweb.cgi?p=aurman;a=shortlog;h=refs/heads/ma... Here is the mailing list: https://lists.berlios.de/mailman/listinfo/aurman-dev Best Regards, Laszlo Papp

On Tue, Oct 20, 2009 at 12:11 AM, Callan Barrett 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

...

for AUR to be a command-line based application like pacman. Well, I'd

...

to see a more robust, and efficient impelementation of it, not a web

On Tue, Oct 20, 2009 at 3:52 AM, Laszlo Papp wrote: like like based

...

application.

We started to redesign PKGINFO related things: http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz

You can see here the state of it here:

http://git.berlios.de/cgi-bin/gitweb.cgi?p=aurman;a=shortlog;h=refs/heads/ma...

...

Here is the mailing list: https://lists.berlios.de/mailman/listinfo/aurman-dev

Best Regards, Laszlo Papp

I don't think I follow. Is this a client to the current AUR or some sort of server for clients?

-- Callan Barrett

It will be a client at this momment for current AUR, but we plan to implement a full backend,api,front for the AUR and package management. It's not a small work for me/us, so be patient, but as I guess the AUR web application/server/backend can be changed for a command line tool, because I like it as I like AUR installer, vim and other command line application. I tried/try to be close to the pacman source codebase, if someone would like to contribute and know the source of pacman, he/she can do it easier, but I'm not a good programmer like Xavier and Dan now :P Btw, any opinion/suggestion would be nice or this: http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz Best Regards, Laszlo Papp

TOP POST Maybe I'm missing something but wouldn't it be better if you did the backend first and then worked on the client. Otherwise you need to rewrite everything in the client and it's just wasted work. Also why are you using the pacman code as a base for the client? I'd rather pacman handled the packages rather than a separate maintained tool. Sent from my iPhone On 20/10/2009, at 10:02 AM, Laszlo Papp wrote:

On Tue, Oct 20, 2009 at 12:11 AM, Callan Barrett

...

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

...

for AUR to be a command-line based application like pacman. Well, I'd

...

to see a more robust, and efficient impelementation of it, not a web

On Tue, Oct 20, 2009 at 3:52 AM, Laszlo Papp wrote: like like based

...

application.

We started to redesign PKGINFO related things: http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz

You can see here the state of it here:

http://git.berlios.de/cgi-bin/gitweb.cgi?p=aurman;a=shortlog;h=refs/heads/ma...

...

Here is the mailing list: https://lists.berlios.de/mailman/listinfo/aurman-dev

Best Regards, Laszlo Papp

I don't think I follow. Is this a client to the current AUR or some sort of server for clients?

-- Callan Barrett

It will be a client at this momment for current AUR, but we plan to implement a full backend,api,front for the AUR and package management. It's not a small work for me/us, so be patient, but as I guess the AUR web application/server/backend can be changed for a command line tool, because I like it as I like AUR installer, vim and other command line application. I tried/try to be close to the pacman source codebase, if someone would like to contribute and know the source of pacman, he/she can do it easier, but I'm not a good programmer like Xavier and Dan now :P

Btw, any opinion/suggestion would be nice or this: http://louipc.mine.nu/arch/Step-1-PKGINFO-in-srctargz

Best Regards, Laszlo Papp

On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp wrote:

I started aurman project as a simple frontend for AUR, then I realised the new idea later for it to be able to be a backend, api, frontend too.

I see where you're coming from but I still think you should start at the backend.

I needn't to rewrite everything in the client, because I tried/try to write the code in portable way, just see the json api interface, It's available from C too, with the same output that the frondend parses(I maintain the jsonapi-c in AUR too). You could see from me patch with json-interface related thingds, because of this. Tell the truth mysql api in C is good enough to get the data from the AUR database, and giving back json interface related output. Summary: it's absolutely not a wasted work, nevertheless I got some internal operations from AUR, and it's cool to get such an experience too :)

It's just that the JSON interface is likely to change in an overhaul and if your application is written correctly interfacing with the AUR this way should be the biggest part of it. I'm not sure I get how this is work not lost.

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.

I don't understand how they're similiar either. As far as I'm concerned this is how an AUR command line utility should work: if you tell it to get a certain package it would get that, *MAYBE* run makepkg as some sort of wrapper and *MAYBE* run pacman as a wrapper to install it. Nowhere in that process should the aur tool touch the produced package or manage any sort of database of packages which is what I thought the entire point of libalpm was.

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.

Having third party dependencies is unavoidable when you're creating a tool that just manages skeleton files for building packages. If you want to automate the process of building and installing packages you've really got no choice but to act as a wrapper to the proper tools for this job, not roll your own version of everything. If you do this the project will never be official and probably will be impossible to maintain considering you're duplicating the efforts of both the pacman and makepkg team plus your own work. -- Callan Barrett

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.

On Tue, Oct 20, 2009 at 4:51 PM, Laszlo Papp wrote:

On Tue, Oct 20, 2009 at 1:05 PM, Sebastian Nowicki wrote:

...

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

...

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

...

to see a more robust, and efficient impelementation of it, not a web

I think AUR2 would be just a temporary solution for our final purposes. I like 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? More on this topic later. Cheers. -- Ryan Coyner [http://ryancoyner.com]

On Sun, Oct 25, 2009 at 4:25 AM, Ryan Coyner wrote:

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.

I had a look at your parser, and it might get the job done now, but I think it's too specific and rigid to allow for extensions to the PKGBUILD format. For instance the recent "split package" support would be quite hard to get working with your design. I have started prototyping another parser, which is a more general bash parser (but specific to PKGBUILDs). It will actually have a symbol lookup table and handle functions and conditionals properly (at least seemingly so). This should reduce code duplication (as was the case with many variables in harc), make it flexible and easier to maintain. I have published the code on github[1], but I advise against cloning it, as I will be altering history. I think this is a better direction to take with the parser, rather than hardcoding the variable formats (url, email, number, etc - they're all strings in bash) and such.

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

I think for the time being, simply porting the current AUR (with some modifications) to a new, more flexible and maintainable system is critical. It should be much easier to change implementation details later.

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.

I don't really see a reason to get rid of the PKGBUILD format. Sure it's a little hard to parse, but once a parser has been developed, there's no problem. It has all the metadata of the package, and we need to store the PKGBUILD (and other source files) on the server anyway. There's no point in duplicating that data. Are you referring to makepkg in general, or just AUR here? If just AUR I think having a separate Makefile for the build() function is a bit overkill - Makefiles are basically bash scripts wrapped in rules. Why take a bash function out of a bash script to put it in a Makefile which contains bash scripts? If for makepkg, well maybe there is a better format than PKGBUILDs, but if we were to change the format, I think something more controllable would be better (abstract functions that get parsed and executed safely - not bash scripts). However, that's a bit off-topic. XML, JSON, YAML and other formats are good for the API. The current API uses JSON, and it seems to be the best format. It's easy to parse and concise. I have started designing a comprehensive API on the wiki[2].

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?

I agree that some consistency would be nice, but I think PKGBUILDs are the best choice for AUR, as stated above. As far as I'm concerned, formats that pacman deals with are irrelevant. For AUR, the only relevant application in makepkg. P.S. It seems my previous mail didn't go through. [1] http://github.com/sebnow/pkgparse/tree/experimental [2] http://wiki.archlinux.org/index.php/AUR_2#API

On Sun, Oct 25, 2009 at 3:13 PM, Laszlo Papp wrote:

On Sun, Oct 25, 2009 at 7:52 PM, Sebastian Nowicki wrote:

...

On Sun, Oct 25, 2009 at 4:25 AM, Ryan Coyner wrote:

...

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.

I had a look at your parser, and it might get the job done now, but I think it's too specific and rigid to allow for extensions to the PKGBUILD format. For instance the recent "split package" support would be quite hard to get working with your design. I have started prototyping another parser, which is a more general bash parser (but specific to PKGBUILDs). It will actually have a symbol lookup table and handle functions and conditionals properly (at least seemingly so). This should reduce code duplication (as was the case with many variables in harc), make it flexible and easier to maintain. I have published the code on github[1], but I advise against cloning it, as I will be altering history.

I think this is a better direction to take with the parser, rather than hardcoding the variable formats (url, email, number, etc - they're all strings in bash) and such.

Yeah, I agree with Sebastian here, we spoke with him about it no need for hardcoding, and for some code duplication.

Sounds good to me.

...

...

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

I think for the time being, simply porting the current AUR (with some modifications) to a new, more flexible and maintainable system is critical. It should be much easier to change implementation details later.

Yeah, but the principle is to be as compatible with the 'old' AUR as we can, so most of the informations from the database is good to follow.

By more flexible and maintanable, I'm assuming the implementation of an API (to allow clean, command line and web access) and the port of the web interface to Django which is definitely a much more maintainable framework. +1 for this notion.

...

...

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.

I don't really see a reason to get rid of the PKGBUILD format. Sure it's a little hard to parse, but once a parser has been developed, there's no problem. It has all the metadata of the package, and we need to store the PKGBUILD (and other source files) on the server anyway. There's no point in duplicating that data.

Are you referring to makepkg in general, or just AUR here? If just AUR I think having a separate Makefile for the build() function is a bit overkill - Makefiles are basically bash scripts wrapped in rules. Why take a bash function out of a bash script to put it in a Makefile which contains bash scripts? If for makepkg, well maybe there is a better format than PKGBUILDs, but if we were to change the format, I think something more controllable would be better (abstract functions that get parsed and executed safely - not bash scripts). However, that's a bit off-topic.

I don't think so too Makefile will be okay for bash script handling, in fact I've never seen Makefile, or autobuild systems for bash scripts :) Their purposes is not relevant here, and it would change things unneccesarily.

Regarding JSON/Makefile, I was suggesting that we dump the PKGBUILD format altogether and use JSON to carry the metadata and a Makefile to substitute for the build function. Now, to draw some comparisons: Advantages of the PKGBUILD format: 1) It's a simple format allows new users to easily contribute to the AUR. 2) It encapsulates both metadata and build instructions in a single file. Again, promotes simplicity for the user. 3) No need to hack up makepkg. Advantages of JSON/Makefile: 1) JSON is a standardized format. Very 3rd party friendly. 2) It removes a layer of abstraction that the PKGBUILD format introduces. Using JSON, you can serialize the metadata and serve that directly to the web interface. This is very easy to do using Django and simplejson. With the PKGBUILD format, you have to parse it first to serve it as JSON... it violates the KISS principle from an engineering perspective. 3) No need to write our custom parser. This is key, in my opinion. Instead, we'd have to hack up makepkg to accept this new format. Doing that is a lot easier.

...

XML, JSON, YAML and other formats are good for the API. The current API uses JSON, and it seems to be the best format. It's easy to parse and concise. I have started designing a comprehensive API on the wiki[2].

Yeah, as I said more times hehe :) I support absolutely these interfaces, mainly JSON, JSON is easy to handle and very portable among languages, so it's cool, and at last we were compatible with the 'old' AUR, so maybe the existing frontend could do their work with smaller modifications.

...

...

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?

I agree that some consistency would be nice, but I think PKGBUILDs are the best choice for AUR, as stated above. As far as I'm concerned, formats that pacman deals with are irrelevant. For AUR, the only relevant application in makepkg.

P.S. It seems my previous mail didn't go through.

[1] http://github.com/sebnow/pkgparse/tree/experimental [2] http://wiki.archlinux.org/index.php/AUR_2#API

It's true the only relevant application is makepkg, but you need to install the whole pacman package into this, so if we needed to install it, then we can use some visible functions from the libalpm too, like common functions from it.

I spoke with Sebastian about the new database schema for AUR, and he gave me a starting point for it, it's a very important point of the new generation AUR for me to be able to start to work on the server side code, mainly on mysql queries, inserting, so please take your opinion/suggestion for it.

http://djszapi.homelinux.net/new_database.schema

My only suggestion is to keep TU_Votes, TU_VoteInfo tables in the database at first glance.

Best Regards, Laszlo Papp

One thing to note is licenses. Some software have custom licenses - how is that going to be represented? Another thing to keep in mind is possible integration of the user accounts with other services for the future (bugs, forums, etc). It would be ideal if the schema is scalable enough to take that into factor. -- Ryan Coyner [http://ryancoyner.com]

On Mon, Oct 26, 2009 at 6:58 AM, Ryan Coyner wrote:

...

...

I think for the time being, simply porting the current AUR (with some modifications) to a new, more flexible and maintainable system is critical. It should be much easier to change implementation details later.

Yeah, but the principle is to be as compatible with the 'old' AUR as we can, so most of the informations from the database is good to follow.

By more flexible and maintanable, I'm assuming the implementation of an API (to allow clean, command line and web access) and the port of the web interface to Django which is definitely a much more maintainable framework.

+1 for this notion.

Yes. The Django port is fairly far along, and the API I mentioned earlier should allow for all tasks to be carried out by 3rd part clients.

Regarding JSON/Makefile, I was suggesting that we dump the PKGBUILD format altogether and use JSON to carry the metadata and a Makefile to substitute for the build function. Now, to draw some comparisons:

Advantages of the PKGBUILD format:

1) It's a simple format allows new users to easily contribute to the AUR. 2) It encapsulates both metadata and build instructions in a single file. Again, promotes simplicity for the user. 3) No need to hack up makepkg.

4) The format allows for variables and control structures. This could be implemented (at least variables) with JSON, but then we no longer have JSON advantage #1. Being able to use $pkgname and $pkgver is _very_ useful. If we want to change the PKGBUILD format, we have to take it up with makepkg devs, and see what they think about it. I think it's unlikely that they will want to change anything. The current format servers its purpose well.

One thing to note is licenses. Some software have custom licenses - how is that going to be represented?

A url field pointing to the license?

Another thing to keep in mind is possible integration of the user accounts with other services for the future (bugs, forums, etc). It would be ideal if the schema is scalable enough to take that into factor.

I think this is out of AUR's scope. I generally see AUR (at least the frontend) as a generic package browser - just like the one on the main page. It shouldn't integrate, or even care about other Archlinux-specific services. The current schema is just taken from the Django AUR2 app, and the account schema is from Django's built-in auth app. As far as Django goes, it's already scalable (all other apps use the same data). I'm not sure how one would make it more scalable to integrate with other web apps - they aren't consistent in that respect.