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.
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
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 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.
On Mon, Oct 19, 2009 at 4:05 PM, Sebastian Nowicki <sebnow@gmail.com> 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 3:52 AM, Laszlo Papp <djszapi@archlinux.us> 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.
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
On Tue, Oct 20, 2009 at 12:11 AM, Callan Barrett <wizzomafizzo@gmail.com>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 <djszapi@archlinux.us> 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 10/19/2009 07:02 PM, Laszlo Papp wrote:
On Tue, Oct 20, 2009 at 12:11 AM, Callan Barrett<wizzomafizzo@gmail.com>wrote:
On Tue, Oct 20, 2009 at 3:52 AM, Laszlo Papp<djszapi@archlinux.us> 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.
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
I think this is a great thing and once we're able to build this backend and api, I would love to see another webapp be put up. I would definitely enjoy being able to use the command-line and a webapp to manage AUR packages (both as a user and maintainer). I'm not too familiar with the pacman code, but I'll help out where I can. I've also joined the aurman mailing list. I saw the aurman stub in the Wiki. Perhaps we should point to that from the AUR2 page? I can maintain the Wiki if need be.
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 <djszapi@archlinux.us> wrote:
On Tue, Oct 20, 2009 at 12:11 AM, Callan Barrett <wizzomafizzo@gmail.com
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 <djszapi@archlinux.us> 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 4:03 AM, Callan Barrett <wizzomafizzo@gmail.com>wrote:
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
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 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 :) 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
On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp <djszapi@archlinux.us> 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 Tue, Oct 20, 2009 at 7:55 AM, Callan Barrett <wizzomafizzo@gmail.com>wrote:
I started aurman project as a simple frontend for AUR, then I realised
On Tue, Oct 20, 2009 at 12:17 PM, Laszlo Papp <djszapi@archlinux.us> wrote: 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'm working on the backend, api now.
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've never said it's a small work with few C source lines so I agree with you in this regard, but my implementations until now it's useful and will be used, so it's not a big work losing, I just need to conitnue with the api, backend implementation and I'm working on it.
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
Hm, yeah Callan, I need to say I agree with you here too, so current implementation with pacman, makepkg wrapper facility may remain, and needed some extension for it. I don't know in fact 'aurman' and similar application can ever be official supproted, I don't know exactly the arch policy in this way. Thanks your feedback :) Best Regards, Laszlo Papp
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 1:05 PM, Sebastian Nowicki <sebnow@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
On Tue, Oct 20, 2009 at 4:51 PM, Laszlo Papp <djszapi@archlinux.us> wrote:
On Tue, Oct 20, 2009 at 1:05 PM, Sebastian Nowicki <sebnow@gmail.com> 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]
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.
We talked about it with Louipc, Sebastian yesterday so much. Your yacc/lex/bison implementation is worth to give a try I think so. Short summary of the yesterday talking on #archlinux-aur, just for our fresh informations (please fix me, if I'm wrong with it): 1) PKGINFO can contain duplicated and unneccesary data and it's support only for AUR project at this momment (however it would be good if ABS would be refactored), so this is hard to be accepted by pacman developers to establish it. 2) Current PKGBUILD parsing is hard from C, easier from bash and python but not so easy with CARCH related parts of it. 3) Give a try with yacc/lex/bison handling, it would be just building dependency, not runtime. I dealt with the server and frontend part of this project recently, but not so much with json-api interface establishing between the server and the frontend. It's important to establish a good server program and API for frontends to be able to handle it easily. I will commit some server related codes soon into the aurman project, any feedback will be welcomed :) But it will be needed to rewrite as the AUR database will be changed (I hope it will be changed.), but it will be extension than a totally rewritten database in my opinion, but anything can occur. I think it's needed to change the database schema too, because it has got some lack of informations now. (e.g. registration date of a user, etc.) 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.
As I told in this thread earlier, I support JSON interface, because it's well supported in scripting/programming languages and relatively easy to handle, so it could be a good unity in this project. I don't think Makefiles would be an easy task for pacman developer to accept it.
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]
It's a duplicated question maybe :P If you can establish your yacc/lex 'interface', PKGBUILD can be more than enough for this problem even if it's not so easy to parse it. Best Regards, Laszlo Papp
On Sun, Oct 25, 2009 at 4:25 AM, Ryan Coyner <rcoyner@gmail.com> 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 7:52 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On Sun, Oct 25, 2009 at 4:25 AM, Ryan Coyner <rcoyner@gmail.com> 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.
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.
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.
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
On Sun, Oct 25, 2009 at 3:13 PM, Laszlo Papp <djszapi@archlinux.us> wrote:
On Sun, Oct 25, 2009 at 7:52 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On Sun, Oct 25, 2009 at 4:25 AM, Ryan Coyner <rcoyner@gmail.com> 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]
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
On Mon, Oct 26, 2009 at 6:58 AM, Ryan Coyner <rcoyner@gmail.com> 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.
participants (5)
-
Callan Barrett
-
Dave
-
Laszlo Papp
-
Ryan Coyner
-
Sebastian Nowicki