Re: @INC changes on Perl upgrade
On Fri, Feb 17, 2006 at 12:55:23PM +1100, Brendan O'Dea wrote:
> On Thu, Feb 16, 2006 at 01:52:12PM -0800, Bill Moseley wrote:
> Typically, a local admin installs a package to the site dirs because:
>
> * a newer version is required than is provided by CORE/vendor (long
> stable release cycles).
As is my case.
> The theory is that at time of upgrading to the next stable release, the
> CORE or vendor versions will be the most current, and should be
> preferred over the module installed locally.
Which isn't the case.
> These assumptions do not necessarily hold for people tracking unstable,
> although generally should not be *too* far off the mark if the perl
> module packagers are following upstream releases relatively promptly.
Seems like going form 5.8.7 to 5.8.8 is not a major upgrade, so it
should not override my locally installed modules.
> In your specific case, I note that libclass-dbi-perl is "out of date"
> since the maintainer is waiting for upstream to release a stable
> version[1] before updating the package. Suggest you simply un-install
> libclass-dbi-perl.
That was my first idea, but then I saw this:
The following packages will be REMOVED:
libcatalyst-model-cdbi-perl libclass-dbi-abstractsearch-perl
libclass-dbi-asform-perl libclass-dbi-fromcgi-perl libclass-dbi-loader-perl
libclass-dbi-loader-relationship-perl libclass-dbi-pager-perl libclass-dbi-perl
libclass-dbi-pg-perl libclass-dbi-plugin-retrieveall-perl
libclass-dbi-plugin-type-perl libclass-dbi-sqlite-perl libmaypole-perl
0 upgraded, 0 newly installed, 13 to remove and 24 not upgraded.
That looks like like an invitation to a fun few hours putting those
back together with CPAN.
It was easier to simply move the old Class::DBI out of the way and
wait for the deb maintainer to, well, wait for Tony to release the next
stable Class::DBI.
But, yes, that's the real answer -- pick one package system and stick
with it. Then I would not have Class::DBI in two different places,
just waiting for a conflict to happen -- like upgrading to 5.8.8.
Anyway, I'm using a module from CPAN, Class::DBI::Sweet, that
depends on Class::DBI 3.0.12. So I had both of those installed via
CPAN in the 5.8.7 directory. But then upgrading perl to 5.8.8
changed the order of @INC, so then I was using the same version of
Class::DBI::Sweet with Class::DBI 0.96. And things broke.
I'm running Sid, so I have to expect things to break once in a while.
And the real problem is I'm mixing packaging systems. I used to be
more careful and make debs out of every CPAN modules I needed to
install.
My little rant...
The real problem, IMO, is CPAN. It's great as a place to share
modules, but sucks as a packaging system. Try installing Catalyst
non-root on a clean Debian Stable using CPAN and things fail
repeatedly -- having to switch CPAN.pm's config over and over to deal
with Module::Build and MakeMaker's different installation settings.
And I'm not alone with this trouble:
http://lists.rawmode.org/pipermail/catalyst/2006-February/thread.html#5093
And my experience:
http://lists.rawmode.org/pipermail/catalyst/2006-February/005110.html
As I mentioned on that thread, it's amazing that something as mature
as Perl doesn't have a better package management system. Of course,
you get used to using .debs and anything else seems so archaic. ;)
Thanks for the feedback,
--
Bill Moseley
moseley@hank.org
Reply to: