[pacman-dev] perl module repo
Just thought I'd drop a note in here. After quite a bit of hacking on cpan4pacman and my own perl scripts, I've finally been able to put together a repository of perl modules which solve many of the problems I mentioned earlier perl-module whine-o-rama. :) Shadowhand was gracious enough to allow me to host an external version of this repository on his box. http://wiki.archlinux.org/index.php/PerlCPAN_Repository The build process is fairly error-free at this point, though it took more than a week of hacking to get it error-free. :) The process works something like this.... 1. Every night my cpan modules list is updated via a cron job. 2. About 30 minutes later, I scrape the above url for modules to build. 3. If there is a difference between the cpan module version and the repo version, the module is built, and a build-report is generated. 4a. The next morning I commit any changes to the repo via svn. 4b. I have code ready to auto-commit changes to the repo, but I'd like let things run for a week or two before I allow the script to bypass the last vestiges of human control of the process. :) Before I make any real annoucements on the BBS, I was wondering if a few of you could subscribe to the repo and let me know that it seems to be working okay. It works fine *for me*, but that does not mean this process or the repo itself is robust enough for general use. I need beta testers! It will be great to see cpan or cpanplus integrated into pacman, but I think this works as a great near-term solution or a long-term alternative. -- Take it easy, Charles FSF Apologist, WikiNut, Concrete Analyst, etc. JABBER: cmauch@gmail.com GIZMO: charlesmauch AIM: cmauch5 :: C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void.
On 10/17/06, Charles Mauch <cmauch@taclug.org> wrote:
The build process is fairly error-free at this point, though it took more than a week of hacking to get it error-free. :)
The process works something like this....
1. Every night my cpan modules list is updated via a cron job. 2. About 30 minutes later, I scrape the above url for modules to build. 3. If there is a difference between the cpan module version and the repo version, the module is built, and a build-report is generated. 4a. The next morning I commit any changes to the repo via svn. 4b. I have code ready to auto-commit changes to the repo, but I'd like let things run for a week or two before I allow the script to bypass the last vestiges of human control of the process. :)
This is rather ingenious. I actually think this makes far more sense than what I had in mind. I'm sure Xentac has a comment or two on this. The idea I had was to use the libalpm bindings to create a perl frontend which grabbed things from CPAN and wrote db information upon install. This would tie together with some meta naming.... i.e. perl:libxml would call the perl plugin. This is actually a superior idea IMO, and could be extended infinitely (to python, et al) and not require a complex plugin system in pacman to do this. Could you please publish your scripts and any changes you made somewhere?
It will be great to see cpan or cpanplus integrated into pacman, but I think this works as a great near-term solution or a long-term alternative.
Just out of curiosity, what would be the benefit, in your eyes, of integrating cpan directly into pacman rather than auto-generating packages like this?
On Wed, 18 Oct 2006 13:08:56 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 10/17/06, Charles Mauch <cmauch@taclug.org> wrote:
The build process is fairly error-free at this point, though it took more than a week of hacking to get it error-free. :)
The process works something like this....
1. Every night my cpan modules list is updated via a cron job. 2. About 30 minutes later, I scrape the above url for modules to build. 3. If there is a difference between the cpan module version and the repo version, the module is built, and a build-report is generated. 4a. The next morning I commit any changes to the repo via svn. 4b. I have code ready to auto-commit changes to the repo, but I'd like let things run for a week or two before I allow the script to bypass the last vestiges of human control of the process. :)
This is rather ingenious. I actually think this makes far more sense than what I had in mind. I'm sure Xentac has a comment or two on this.
Comments... let's see... What happens if a build fails? That's my biggest concern. What about dependencies? Is this a clean system building packages or could dependencies sneak in without us having a way to tweak them? Don't get me wrong, it's definitely a good idea. I'm still noodling it, but on the surface, it seems good.
The idea I had was to use the libalpm bindings to create a perl frontend which grabbed things from CPAN and wrote db information upon install. This would tie together with some meta naming.... i.e. perl:libxml would call the perl plugin.
This is actually a superior idea IMO, and could be extended infinitely (to python, et al) and not require a complex plugin system in pacman to do this.
This is one of the reasons I wrote pacbuild... too bad it's still not done... While the actual building is only one part of this, you'd need something if it was extended to all packages. Jason
On 10/18/06, Jason Chu <jason@archlinux.org> wrote:
This is actually a superior idea IMO, and could be extended infinitely (to python, et al) and not require a complex plugin system in pacman to do this.
This is one of the reasons I wrote pacbuild... too bad it's still not done... While the actual building is only one part of this, you'd need something if it was extended to all packages.
eww. I looked at python, and while the xmlrpc interface to Pypi is cake, as far as getting information, and the download urls list 'kind' by distutils, eggs, etc etc, there is _no_ dependancy information anywhere, and according to some of the docs, it never will have dependancy info.
On Wed, 18 Oct 2006 16:45:10 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 10/18/06, Jason Chu <jason@archlinux.org> wrote:
This is actually a superior idea IMO, and could be extended infinitely (to python, et al) and not require a complex plugin system in pacman to do this.
This is one of the reasons I wrote pacbuild... too bad it's still not done... While the actual building is only one part of this, you'd need something if it was extended to all packages.
eww. I looked at python, and while the xmlrpc interface to Pypi is cake, as far as getting information, and the download urls list 'kind' by distutils, eggs, etc etc, there is _no_ dependancy information anywhere, and according to some of the docs, it never will have dependancy info.
Eggs should have dependency info inside them. Anything easy_installable should be pretty good about that sort of stuff. If it's not setuptools-able, that's when you'll run into trouble. Jason
participants (3)
-
Aaron Griffin
-
Charles Mauch
-
Jason Chu