This is not a joke even for many people Debian stands for - although stable and working but quite old versions. The important is that the Debian stable stays stable for a few years. Ageing versions is the trade of for the least amount of surprises. But actually we all need new/recent versions. Not for everything but for the SW/packages that we really use. So what has Debian to offer in this case?
1. install from source
we'll there is not too much to discuss this, everyone can use CPAN shell,
compile Apache or use `./configure && make && make install` like in any other
Linux distribution.
2. back-porting
There are already made backports
just to take. There are some tutorials how to do it
on the web and
there is plenty more info just use the search engine.
Basically what the process involves is to add sources line to
3. packaging on-your-own
There are couple of ways how to package new things. If the CPAN module is already package with some
older version, a good start is to get the source of that old version and reuse the debian/ folder
from it by copying it to the extracted recent version. In most cases updating debian/changelog
and the new dependencies in debian/control will be all the steps for packaging. If the module is
not packaged then you can try `dh-make-perl --cpan Moose`. This script will download recent Moose
and will try the best it can to prepare all files in debian/ folder. Even better tool is
offered by CPANPLUS
+CPANPLUS::Dist::Deb.
A command `cpan2dist --verbose --format CPANPLUS::Dist::Deb Moose` will create cpan-libmoose-perl
with recent dependencies "compatible" with system Perl. More info and an automated repository can
be found @http://debian.pkgs.cpan.org/.
4. mixing releases
Mixing releases is a way how to install only minimum subset of testing/unstable packages to the stable
release, as everyone has a different needs and taste. How? Set the
# lenny (stable)
deb http://ftp.cz.debian.org/debian/ lenny main non-free contrib
deb-src http://ftp.cz.debian.org/debian/ lenny main non-free contrib
deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free
# squeeze (testing)
deb http://ftp.cz.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.cz.debian.org/debian/ testing main non-free contrib
# sid (unstable)
deb http://ftp.cz.debian.org/debian/ unstable main non-free contrib
#deb-src http://ftp.cz.debian.org/debian/ unstable main non-free contrib
and
Package: *
Pin: release a=stable
Pin-Priority: 800
Package: *
Pin: release a=testing
Pin-Priority: 700
Package: *
Pin: release a=unstable
Pin-Priority: 600
Now even when running `apt-get update && apt-get dist-upgrade` no new versions from testing will be installed. To install a new version from testing || unstable use `apt-get install -t testing libmoose-perl`. Here is what Moose will bring along with him:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libalgorithm-c3-perl libclass-c3-perl libclass-mop-perl libdata-optlist-perl libdevel-globaldestruction-perl liblist-moreutils-perl
libmro-compat-perl libparams-util-perl libscope-guard-perl libsub-exporter-perl libsub-install-perl libsub-name-perl
libsub-uplevel-perl libtest-exception-perl perl perl-base perl-modules
Suggested packages:
perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl
Recommended packages:
libclass-c3-xs-perl netbase
The following NEW packages will be installed:
libalgorithm-c3-perl libclass-c3-perl libclass-mop-perl libdata-optlist-perl libdevel-globaldestruction-perl liblist-moreutils-perl
libmoose-perl libmro-compat-perl libparams-util-perl libscope-guard-perl libsub-exporter-perl libsub-install-perl libsub-name-perl
libsub-uplevel-perl libtest-exception-perl
The following packages will be upgraded:
perl perl-base perl-modules
3 upgraded, 15 newly installed, 0 to remove and 62 not upgraded.
Need to get 9617kB of archives.
After this operation, 4431kB of additional disk space will be used.
Do you want to continue [Y/n]?
...
Setting up perl-modules (5.10.0-22) ...
Setting up perl (5.10.0-22) ...
Setting up libalgorithm-c3-perl (0.08-1) ...
Setting up libsub-uplevel-perl (0.2002-1) ...
Setting up libtest-exception-perl (0.27-2) ...
Setting up libclass-c3-perl (0.21-1) ...
Setting up libsub-name-perl (0.04-1) ...
Setting up libmro-compat-perl (0.10-1) ...
Setting up libscope-guard-perl (0.03-2) ...
Setting up libsub-install-perl (0.924-2) ...
Setting up libparams-util-perl (0.38-2) ...
Setting up libdata-optlist-perl (0.104-1) ...
Setting up libsub-exporter-perl (0.981-1) ...
Setting up libdevel-globaldestruction-perl (0.02-1) ...
Setting up libclass-mop-perl (0.81-1) ...
Setting up liblist-moreutils-perl (0.22-1+b1) ...
Setting up libmoose-perl (0.74-1) ...
If you want to go even further then just do `apt-get install -t unstable libmoose-perl`:
...
Setting up libclass-mop-perl (0.85-1) ...
Setting up libmoose-perl (0.80-1) ...
Cool, isn't it? And what if something does wrong? (What could possibly go wrong?) You can check what is in the system from testing/unstable simple via `apt-show-versions | grep -E '/(testing|unstable)'`:
libalgorithm-c3-perl/testing uptodate 0.08-1
libclass-c3-perl/testing uptodate 0.21-1
libclass-mop-perl/unstable uptodate 0.85-1
libdata-optlist-perl/testing uptodate 0.104-1
libdevel-globaldestruction-perl/testing uptodate 0.02-1
libmoose-perl/unstable uptodate 0.80-1
libmro-compat-perl/testing uptodate 0.10-1
libparams-util-perl/testing uptodate 0.38-2
libsub-exporter-perl/testing uptodate 0.981-1
libsub-uplevel-perl/testing uptodate 0.2002-1
libtest-exception-perl/testing uptodate 0.27-2
perl/testing uptodate 5.10.0-22
perl-base/testing uptodate 5.10.0-22
perl-modules/testing uptodate 5.10.0-22
Do you want your Moose 0.74 back? Just do `apt-get install libmoose-perl/testing`. Well and it is possible to exercise this sort of "fun" on your own internal company repositories having stable/testing/unstable for your own projects with a possible way how to get back.
Still anyone thinks that CPAN shell must be enough for everyone ;-) It's good for many but when it comes to bigger projects and maintenance of many servers, it's no more enough.
Despite the name, testing is generally quite stable. You might not want to run a critical piece of infrastructure on it, but it should be good enough for anything MySQL is good enough for.
But I don't manage Perl modules from the OS. I leave the system Perl alone and manage my own in another directory.
Re:I just use testing
nicholasrperez on 2009-06-10T17:43:49
Here here to this suggestion. I've been bitten one too many times mixing cpan and apt-get usage. It is always better to let the OS do what it wants with its perl and manage a completely separate build and set of paths, etc of perl.
Re:Not updated
jozef on 2009-06-11T10:03:21
Did you try to send email to Jos? May be it's not updated because he sees not enough community interest?
Does that mean one could install Padre from Unstable even on systems running testing or stable ?
Re:Installing Padre from Untsable
jozef on 2009-06-15T08:17:47
Well yes and no. In principle yes, currently no, as `sudo apt-get install -t unstable padre` fails atm.:
The following packages have unmet dependencies:
padre: Depends: libfile-path-perl (>= 2.07) but it is not installable
File::Path is part of "perl" package and should not be in dependecies. The required (unstable?) Perl version should be listed.
