Managing CPAN on Arch Linux

So if you're running Arch Linux and want to install a bunch of packages from CPAN the best way is NOT to use the official cpan client, or even the new cpanminus. No your best bet is to use AUR or lacking AUR packages, create your own, and I'm gonna walk you through how I do it. The really nice thing about installing packages with Pacman is that unlike cpan there is a utility to uninstall them.

The first thing you'll want is a utility that allows you to easily manage aur. Right now the Recommended tool appears to be a CLI utility called packer you'll want to download the PKGBUILD, on the packer page, to a directory of it's own and run makepkg -s in that directory and then (as root) pacman -U pkgname-pkgver.pkg.tar.gz. You've now installed Packer, which means you'll never have to install an AUR package like that again (barring a new install of arch). If you really want you can stop now and just use the packages provided by arch, myself, and other aur contributors. The general conversion in name is is the CPAN module DBIx::Class becomes perl-dbix-class. However running packer dbix-class will find it. packer is capable of searching all of aur and the official repositories and giving you options if more than one is available. If you want to learn how to make your own packages, or just plain ignore aur and use cpanp to install read on.

So now you'll want to install CPANPLUS with packer. This is easy just run packer perl-cpanplus. This should install CPANPLUS and any of its deps. Now install CPANPLUS::Dist::Arch
with packer perl-cpanplus-dist-arch. There are other 'cpan' options but this is the only one that's on both CPAN and AUR, and it has some really nice functionality.

Now you have your entire installer stack but you still need to configure C::D::A. Run setupdistarch. This will configure cpanplus to automatically create any package it creates as an Arch pkg, it can even install them. For example packer perl-moose and cpanp -i Moose will both install Moose with Pacman. The first will use the package I've uploaded to AUR and the second will use C::D::A to create one (which is exactly what I did).

So now you know the basics of Installing packages, but I'm guessing you still want to know, how I'm managing over 200 perl packages. C::D::A is actually making this easier all the time (esp since I talk to the author). first you'll want to create a directory to store all your AUR packages, the name isn't important. So you'll want to create your first package like cpan2aur -d Catalyst::Runtime you'll note that this creates the directory perl-catalyst-runtime in that directory there is a PKGBUILD.tt it contains syntax similar to Template::Toolkit, it is however home grown by the author of C::D::A. you can use it to add stuff the the resulting PKGBUILD. To create the PKGBUILD you'll run cpan2aur perl-catalyst-runtime it will create the PKGBUILD and the tarball for AUR. However, if you're really planning on making this for AUR and no package is on AUR or you own the one on AUR you can just run cpan2aur -u perl-catalyst-runtime and it will create all the aforementioned things plus upload them with your AUR account. It's worth noting that if you attempt to run cpan2aur and a PKGBUILD already exists it will ask you if you wish to overwrite, unless you've made changes to it say yes, if you aren't updating to a new version on cpan it will ask if you want to update the pkgrel. I specifically requested that because it was annoying to increment by hand and I needed to update the PKGBUILD because of things like dep or provides changes.

Unfortunately cpan2aur cannnot generate an entire dep tree worth of directories. It's worth saying that you don't really have to run cpan2aur -d at all, you could just go right to cpan2aur -u, but then you'd miss out on the wonder that is cpan2aur --check. You can run cpan2aur --check perl-* and it will automagically check for updates of any directory that starts with perl- and upload the updates to AUR.

Unfortunately C::D::A has some limitations. The first is that it really Doesn't use Template Toolkit or even Template::Tiny (which I suggested). This doesn't seem to matter to much... but I wonder if it could help me with the other problem. C::D::A can't correctly determine optdepends because it gets the deps from the generated Makefiles. I'm not sure if this could be fixed or not, I don't yet understand this part of making CPAN packages enough.

Happy packaging.

UPDATE:

you don't need cpan2aur -u --check, cpan2aur --check implies -u

Bypassing disabled accounts with KDM

So the most common way of disabling an account in a unix system is changing the users shell in /etc/passwd to /bin/false or /sbin/nologin. However, I've discovered on Arch Linux that if I do this only shell login's are disabled, I was still able to log the user in with gui via kdm. I also tried using usermod --expiredate 1. this was not effective either however. the only way I found to lock the account from kdm login was to do a passwd -l accountname, which only locks password authentication. This means key and token authentication should still work. My real concern is that if the user was set to login without a password that it would still be bypass-able. My personal opinion is that I shouldn't have to do more than 1 thing to disable a user account in a 100% effective manner. Currently Arch Linux (and maybe more) fails at this. I'll post a fix later as I investigate further.

Bugs I filed are at kde and Arch Linux

EDIT: expire date worked... just not immediately, very odd.

EDIT: Here's a proper /etc/pam.d/kde

#%PAM-1.0
auth        required    pam_nologin.so
auth        required    pam_unix.so nullok
auth        required    pam_shells.so
auth required pam_tally.so onerr=succeedfile=/var/log/faillog
account     required    pam_access.so
account     required    pam_time.so
account     required    pam_unix.so
password    required    pam_unix.so
session     required    pam_unix.so
session     required    pam_env.so
session     required    pam_limits.so

Arch, Funtoo, and Regen2's future

as I've been saying here recently I'm burned out, on so many angles it's not funny. I'm apathetic, I'm not really sure I care anymore. I'm actually playing with arch at the moment to see if it's a better fit. I also here debian sid might work. I don't want to maintain the tree 7 days a week anymore, and I'd like an up to date system.

I've been talking w/ drobbins lately about the possibility of a common tree with funtoo, I'm not sure he wants to do it the same way I do, which is unfortunate. doing this might take the load off me that I don't want, but it's entirely possible that it's too late for it to matter.

I'm going to take a few days and see what happens, it's entirely possible that I'm just going to give up at this point. I'll let people know in a few days what I've decided.