[pacman-dev] pacman and perl
I just joined this list to ask a few questions about perl modules in arch, and to explain (whine) about some of the workarounds I've tried to keep my own modules up to date with the CPAN archives. First, I'd like to say that for the most part, the perl modules provided by the arch devs for the most part work fine. But there always seems to one or two that are out of date. This isn't a problem unique to arch, I run a couple of debian boxes and run across the same situation all the time. There are simply so *many* possbile modules it can be an impossible situation to keep current. Because I can't live without the latest and greatest, over time I've come up with a few workarounds that I'd love to eliminate. First, I use pacman.conf to block the installation of a few modules, and keep my own copies maintained. Some packages simply INSIST on being managed by pacman, so in that case - I usually let arch have it's way an download and install what packages I want newer versions of into a ~/perl directory. By setting the PERL5LIB variable, I can ensure my local copy gets used instead. Unfortuatly, my ~/perl directory is growing at a rapid clip in arch. So here are some suggestions I think would make perl hacking in arch easier. 1. Dump whatever perl-module naming scheme (if there is one) for arch perl modules and simply use the CPAN module name. I don't know how many times I'll lookfor Foo::Bar, only to discover pacman's named it perl-bar-foo or some other nonesense. Is there a current naming scheme for modules? 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 do not have a webhost that could host or build this kind of repo, but I'd be happy to help maintain/run such a system. Anyway, some ideas. Thoughts? Am I just spinning my wheels? -- Take it easy, Charles FSF Apologist, WikiNut, Concrete Analyst, etc. :: Playing "Hang Tough" by Fluke (Puppy)
On 18:18 Wed 11 Oct , Charles Mauch wrote:
I just joined this list to ask a few questions about perl modules in arch, and to explain (whine) about some of the workarounds I've tried to keep my own modules up to date with the CPAN archives.
First, I'd like to say that for the most part, the perl modules provided by the arch devs for the most part work fine. But there always seems to one or two that are out of date. This isn't a problem unique to arch, I run a couple of debian boxes and run across the same situation all the time. There are simply so *many* possbile modules it can be an impossible situation to keep current.
Because I can't live without the latest and greatest, over time I've come up with a few workarounds that I'd love to eliminate.
First, I use pacman.conf to block the installation of a few modules, and keep my own copies maintained. Some packages simply INSIST on being managed by pacman, so in that case - I usually let arch have it's way an download and install what packages I want newer versions of into a ~/perl directory. By setting the PERL5LIB variable, I can ensure my local copy gets used instead.
Unfortuatly, my ~/perl directory is growing at a rapid clip in arch.
So here are some suggestions I think would make perl hacking in arch easier.
1. Dump whatever perl-module naming scheme (if there is one) for arch perl modules and simply use the CPAN module name. I don't know how many times I'll lookfor Foo::Bar, only to discover pacman's named it perl-bar-foo or some other nonesense. Is there a current naming scheme for modules?
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 do not have a webhost that could host or build this kind of repo, but I'd be happy to help maintain/run such a system.
Anyway, some ideas. Thoughts? Am I just spinning my wheels?
There is a script (?) called cpan4pacman, I think you can find it in the bbs.archlinux.org (can't give you a link 'cause here it's 3.24 am and I'm quite tired :) . It is amazing, and an official support (with improvements) would be great. HTH -- Alessio 'mOLOk' Bolognino
2006/10/12, Alessio 'mOLOk' Bolognino
There is a script (?) called cpan4pacman, I think you can find it in the bbs.archlinux.org (can't give you a link 'cause here it's 3.24 am and I'm quite tired :) . It is amazing, and an official support (with improvements) would be great.
http://bbs.archlinux.org/viewtopic.php?t=21048 cpan4pacman is a part of perl-cpan-pacman package. -- Roman Kyrylych (Роман Кирилич)
* On Wednesday, October 11 2006, Charles Mauch wrote:
1. Dump whatever perl-module naming scheme (if there is one) for arch perl modules and simply use the CPAN module name. I don't know how many times I'll lookfor Foo::Bar, only to discover pacman's named it perl-bar-foo or some other nonesense. Is there a current naming scheme for modules?
In my opinion, the naming scheme for this should be perl-module-foo-bar. Obescenely long, but it also eliminates the chance of a name colision with a seperate, non-cpan project.
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?
Anyway, some ideas. Thoughts? Am I just spinning my wheels?
Great ideas. // codemac -- .: [ + carpe diem totus tuus + ] :.
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
2006/10/12, Essien Ita Essien
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: . . .
It seems like good solution. IIRC Pacman3 doesn't support "plugins" yet. So there should be work done to add support for --whatever switches to be handled by some sort of plugins. -- Roman Kyrylych (Роман Кирилич)
participants (5)
-
Alessio 'mOLOk' Bolognino
-
Charles Mauch
-
Essien Ita Essien
-
Jeff 'codemac' Mickey
-
Roman Kyrylych