[pacman-dev] pacman and perl

[Essien Ita Essien]

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 at archlinux.org
> http://www.archlinux.org/mailman/listinfo/pacman-dev
>