Jeff 'codemac' Mickey wrote:
* On Wednesday, October 11 2006, Charles Mauch wrote:
<snip>
2. I dont know how reasonable this is, but I would *love* to manage all my packages with the cpan tool. Maybe pacman could act as a wrapper to the cpan command? Or as an alterative, maybe provide an option to install cpan modules instead of packages into some other directory. Yes, I know the implications of something like this on PKGBUILD's might be horrendous. :)
2a. Yes, cpan is horrible at times. An alternative might be cpanplus.
3. Another idea would be to create a small tool which creates pacman style tarball bundles out of *all* the cpan modules once every few weeks, and stores them on a repo somewhere. Something like http://rpmpan.sourceforge.net/ for arch. This would eliminate the need for cpan at all. When i dicovered http://perl.arix.com/cpan2rpm/ I just about sh*t myself the idea was so cool too :)
I feel like 3 is the more reasonable option, but I love the idea of 2. Having cpan built into pacman, so it would download the source from cpan, and then install the files as the appropriate package on your system. The problem there obviously lies in that then we are essentially building parts of makepkg _into_ pacman. Maybe makepkg could be the wrapper?
Option 3 is really easy to implement, but I have a weird idea for making option 2 workable. The idea would also work for perl-cpan, python-easy_install, php-pear, ruby(?), etc... make it pluggable. The scenarios are: A) pacman -Ss 1. pacman -Ss --perl-module searchstring 2. pacman calls the --perl-module plugin which actually uses cpan to do a search, and returns the result. B) pacman -S 1. pacman -S --perl-module acpanmodule 2. pacman calls 'makepkgbuild --perl-module' or 'makepkg --createpkgbuild --perl-module' which generates a cpan module PKGBUILD from a template (/var/lib/makepkg/PKGBUILD.perl-module) 3. created pkgbuild is kept in /tmp/makepkg 4. pacman then calls makepkg -i in that directory. the generated pacman package is moved to /var/cache/pacman/pkg It would appear that cpan4pacman has implemented a mechanism to replace steps 2, and 3, so we could make that a generic pluggable framework for different languages and use that inplace of my steps 2 and 3. C) pacman -A 1. pacman -A --python-module /path/to/pythonmodule.egg 2. Same as pacman -S, but the generated PKGBUILD will have the source in the same directory as the pkgbuild, so no downloading is done. 3. same as (B) 4. same as (B) D) pacman -U (same as -A but uses -f to force an upgrade) E) pacman -Su --perl-module --python-module --ruby-module I have no idea how to do this transparently, since there's no real pacman repo behind it. the only thing I can think about is doing manual upgrades for now. Another idea is that when --lang-module switch is used, the package name will be entered into a special local db (per lang-module), and when -Su --lang-module is invoked, the plugin will know how to check for updates on the language repo and grab an update. F) pacman -R DUH!!! :P The advantages are that we don't need to replicate CPAN, python-cheeseshop and all other language module repositories. A big problem is release numbers. We can choose to: 1) Ignore them, set lease number to empty? 2) Ignore them by setting release number to something visually helpfull -dynamic, -perl-module, -perl, etc. 3) Work with the upstream language module repository maintainers to reach an agreement on release numbers, so they actually make sense. ok... that's the basic idea. poke, poke, poke. I'm willing to do the implementation of this, but lets flog the idea some more a bit. Cheers, Essien
Anyway, some ideas. Thoughts? Am I just spinning my wheels?
Great ideas.
// codemac
------------------------------------------------------------------------
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev