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.
I think it's very big advantages of it. I think the one power of AUR for newbies they can contribute easily with this AUR idea, no need to have proficient knowledge, and not so hard like on gentoo with ebuilds e.g. I like this simple format even it became more difficult with some things, e.g. with split packages.
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.
Yeah, but don't think only in webinterface implementation, me and others would like to do it in another way, so it's needed to be compatible and portable.
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.
Why would pacman developers take such a big change like this because of us ? The package management works without it well now otherwise,so I don't think it would be an easy action to convince the pacman developers here, which can be an important difficulty here. Nevertheless I agree with Sebastian here, and I can repeat him only, "it's a little hard to parse, but once a parser has been developed, there's no problem". And Sebastian suggestion's was such an implementation in yacc/lex way to be able to be as flexible as possible, so if the PKGBUILD format will be changed, we we need to take minimal modifying. So I believe if we need a solution for AUR problem we need to find the solution/implementation instead of convincing the pacman developers.
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]
What would this integration mean ? Yeah I think so, if the schema is scalable at all, like in case of more repository handling for AUR e.g., it's nice if it has got more facility for things. Best Regards, Laszlo Papp