[pacman-dev] pacman and perl
Essien Ita Essien
essiene at datavibe.net
Thu Oct 12 07:37:11 EDT 2006
Jeff 'codemac' Mickey wrote:
> * On Wednesday, October 11 2006, Charles Mauch wrote:
>> 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
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.
>> Anyway, some ideas. Thoughts? Am I just spinning my wheels?
> Great ideas.
> // codemac
> pacman-dev mailing list
> pacman-dev at archlinux.org
More information about the pacman-dev