CPAN "recompile" command

Post by Linda W
CPAN recompile -- is this supposed to update modules to the latest
version or use the existing versions?
I thought it was just supposed to recompile the local sources, yet
when I start with the cygwin perl 5.8.7 dist, and recompile
from there, it downloads the new Compress::Zlib(2.005) (and requires
several pre-reqs not in the 5.8.7 distro).

---
If a freshly installed distro can't "recompile" -- is that a common problem
or somewhat serious? ;^?

Andreas J. Koenig

2007-07-25 04:01:43 UTC

lw> CPAN recompile -- is this supposed to update modules to the latest
lw> version or use the existing versions?

The CPAN.pm shipped with 5.8.[78] is very old. You should probably
upgrade CPAN.pm before you start using it extensively. Then the
upgrade command does what you expect from the recompile command and
the recompile command has a better manpage entry.

But all this sort of questions are not quite appropriate for P5P, you
better ask them on perlmonks.

lw> I thought it was just supposed to recompile the local sources, yet
lw> when I start with the cygwin perl 5.8.7 dist, and recompile
lw> from there, it downloads the new Compress::Zlib(2.005) (and requires
lw> several pre-reqs not in the 5.8.7 distro).

lw> Thanks,
lw> -linda

--
andreas

Linda W

2007-07-25 09:04:23 UTC

Post by Andreas J. Koenig
lw> CPAN recompile -- is this supposed to update modules to the latest
lw> version or use the existing versions?
The CPAN.pm shipped with 5.8.[78] is very old.

---
Yes.

Post by Andreas J. Koenig
You should probably
upgrade CPAN.pm before you start using it extensively.

---
?Why? It's broken and you told me not to try such complex things
when things are broken, anyway... The "recompile" is an
attempted "predecessor" step to "upgrading CPAN.pm".

Let me "recap", since you are suggesting that I do steps I've
already done, that have already failed, and that I'm already
trying to work around. :-/

Originally, it was installing a module for Win32 functions that I
was told (by message in CPAN) that I had an "old" CPAN, and that
I should try upgrading it by installing Bundle::CPAN, and reloading it.

I followed that suggestion 1st. That started pulling in updated, required
pre-reqs (my pre-req-pol is set to 'follow').
While it was building the CPAN bundle and its pre-reqs, I saw scattered
messages about missing pre-reqs, on 1 or more mods; some mods said they
were incompatible with previous versions, and I was seeing regular
error/warning messages about undefined values being used (like $1 in
Util.pm, line 30) -- looking like "corrupted" (or wrongly versioned)
include files were being included.

At that point, I thought the installation might be corrupt, so decided
to reinstall and rebuild all. I did that first with 5.8.8, then back
to 5.8.7. Neither worked cleanly.

At this point, after I'd tried the CPAN bundle, tried rebuilding
and reinstalling out-of-date modules, and tried module rebuilding on top
of fresh 5.8.8 and 5.8.7 installations, that you responded, saying that
"even you" could not repair such an "installation" and that I should have
done "something else" other than trying to update my modules (which I
was trying on top of fresh 5.8.8 and then 5.8.7 cygwin packages). You
told me I'd have to start fresh and reinstall my perl, which was a bit
confusing, as that's what I had been doing and was trying to "upgrade"
the modules after installing the "distros" "downgraded" my core modules.

I.e. the steps you were suggesting were steps I'd already done multiple
times before posting.

One "nasty" problem in this particular "port" was the problem I ran
into trying to upgrade the Bundle::CPAN. One pre-requisite was the
Compress package. The 2.x version is somewhat structured differently from
how the 1.x version was organized. The problem happens when I build/test/install
the new version. By default, it goes into my local "site" library dir, "site_perl".
There, it shadows the "Core" version of Compress.

Unfortunately, the install of the new 2.x Compress fails part way through on
some pre-req (possibly Cwd.dll). This results in some 2.x headers
in the "site_dir", but not the complete set. This results in a
corrupted perl/cpan installation. The broken/incomplete 2.x Compress
shadows the base's 1.x Compress. Then cpan can't unpack distributions
because the "uncompress" part of "Compress" is one of the broken parts. So
the only easy way to continue is to either re-install the distribution (and,
manually remove the site_dir -- a perfectly sane and normal way to
reinstall perl on this platform). Maybe the build scripts on your platform
work, but the scripts porting perl to Win32 aren't as clean as they could
be under linux.

Part of this problem comes from Cwd.dll (PathTools et al) not using
Win32API to install the new library. There seem to be other problems,
but at this point, I'm getting too many overlapping incompatibilities
to make good sense of everything.

Part of the problem, is installing new DLL's over "inuse" DLL's as
demerphq mentioned to Reini. More than one module installed in
cygwin, on windows, fails due to not using demerphq's "Win32API::File".
He says if modules like "Cwd.dll" and "Storable.dll" used his API, they
would upgrade without error, but for whatever reason, they aren't
working under cygwin. Instead, they try to replace files the Unix way
(delete old file, install new one). As a result, they generate an
unhandled exception. This will cause anything that depends on "Cwd",
like Bundle CPAN, to fail when you try to upgrade it. "Fixing" it
requires manually moving the files out of the way and allowing the
install to continue (Storable failure and correction under cpan on cygwin
on winXP2)
...
/usr/bin/make test -- OK
Running make install
Cannot forceunlink /usr/lib/perl5/5.8/cygwin/auto/Storable/Storable.dll: Permision denied at /usr/lib/perl5/5.8/File/Find.pm line 918
Installing /usr/lib/perl5/5.8/cygwin/auto/Storable/libStorable.dll.a
make: *** [pure_perl_install] Error 13
/usr/bin/make install UNINST=1 -- NOT OK

# so the install fails; to work around users are to manually move files out of way and then
# reinstall...

cpan> look Storable #enter dir
Running look for module Storable
Trying to open a subshell in the build directory...
Working directory is /var/cache/CPAN/build/Storable-2.16
# (first try Unix way - delete file; should fail as we are on WinXP)
(2)/var/cache/CPAN/build/Storable-2.16> rm /usr/lib/perl5/5.8/cygwin/auto/Storable/Storable.dll
rm: cannot remove `/usr/lib/perl5/5.8/cygwin/auto/Storable/Storable.dll': Permission denied
# verified as locked, but using Win32API method posted by demerphq:
# a) rename the dll to something else
# b) install the correct dll with the correct name
# c) schedule the old dll for deletion at next boot [if necessary]

# first the move:
(2)/var/cache/CPAN/build/Storable-2.16> \
mv /usr/lib/perl5/5.8/cygwin/auto/Storable/Storable.dll \
/tmp/Storable.dll.to_delete
#
# rename works, now rerun make install...

(2)/var/cache/CPAN/build/Storable-2.16> make install UNINST=1
Installing /usr/lib/perl5/5.8/cygwin/auto/Storable/Storable.dll

# Done! I exit back into CPAN and continue ... slowly cranking
# through the various modules that don't rename or install files
# or that are not working for some other reason "this time around"
# on WinXP

Post by Andreas J. Koenig
Then the
upgrade command does what you expect from the recompile command and
the recompile command has a better manpage entry.

---
The upgrade command has a better manpage entry? ...
home> man CPAN::recompile
No manual entry for CPAN::recompile
home> man CPAN::upgrade
No manual entry for CPAN::upgrade
home> man upgrade
No manual entry for upgrade
----
No mention of a "upgrade" function in the CPAN(3pm) man page either.
Do you use Perl on Cygwin on a Win-NT platform? Maybe that's
adding to the misunderstanding, though I am, sometimes, too
terse in my communications.

Andreas J. Koenig

2007-07-25 10:48:09 UTC

lw> CPAN recompile -- is this supposed to update modules to the latest
lw> version or use the existing versions?

Post by Andreas J. Koenig
The CPAN.pm shipped with 5.8.[78] is very old.

---
Yes.

Post by Andreas J. Koenig
You should probably
upgrade CPAN.pm before you start using it extensively.

---
?Why? It's broken and you told me not to try such complex things
when things are broken, anyway... The "recompile" is an
attempted "predecessor" step to "upgrading CPAN.pm".

"Recompile" is a very old command that had a very limited scope, so
limited that I was close to deprecating it completely. Believe me (for
now) that it is not what you're looking for. I'll have to rewrite the
manpage for version 1.92 again to further discourage its use.

Post by Linda W
Let me "recap", since you are suggesting that I do steps I've
already done, that have already failed, and that I'm already
trying to work around. :-/

Your pain is my pain. Thanks for going through all the hell, it will
hopefully lead to some fixes for cygwin in the future. But you missed
one step that most probably works:

cpan> install CPAN

Yes, nobody suggested it yet but I meant just that when I said you
should upgrade CPAN.pm. This comment should install CPAN.pm 1.9102 and
bring you a bit closer to the present times. After that, leave the
CPAN shell with "quit" and enter it again to take the most
conservative aproach possible.

I repeat only what others have said: in a bootstrapping situation you
should prefer smaller steps so that you can repair one problem case
after the other. Upgrading CPAN.pm is a small step. Installing
Bundle::CPAN is a large step.

Post by Linda W
Originally, it was installing a module for Win32 functions that I
was told (by message in CPAN) that I had an "old" CPAN, and that
I should try upgrading it by installing Bundle::CPAN, and reloading it.

As you have proved by now, Bundle::CPAN cannot be upgraded on cygwin.
I hope that Reini and demerphq and maybe others can lead you through
some of the necessary steps. I cannot. It's a Windows problem and I
have no Windows.

Post by Linda W
[...description of tedious upgrade procedure snipped...]
# Done! I exit back into CPAN and continue ... slowly cranking
# through the various modules that don't rename or install files
# or that are not working for some other reason "this time around"
# on WinXP

Great. You have taken one step forward. I don't know how often you
will have to repeat this procedure. I must leave this part of the
problem area to those porters who have their hands on Windows boxes.

Post by Andreas J. Koenig
Then the
upgrade command does what you expect from the recompile command and
the recompile command has a better manpage entry.

---
The upgrade command has a better manpage entry? ...

home> man CPAN::recompile

Post by Linda W
No manual entry for CPAN::recompile

home> man CPAN::upgrade

Post by Linda W
No manual entry for CPAN::upgrade

home> man upgrade

Post by Linda W
No manual entry for upgrade
----
No mention of a "upgrade" function in the CPAN(3pm) man page either.
Do you use Perl on Cygwin on a Win-NT platform? Maybe that's
adding to the misunderstanding, though I am, sometimes, too
terse in my communications.

With "Then" I was referring to the times after the upgrade of the CPAN
shell and with "manpage" I was referring to the CPAN.pm manpage (the
current one).

--
andreas

Sherm Pendley

2007-07-25 20:36:05 UTC

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W <perl-

As you have proved by now, Bundle::CPAN cannot be upgraded on cygwin.

There's a similar problem with the Perl 5.8.1 that was included with
Mac OS X a few versions back. It's to the point now where the CPAN.pm
that was shipped with the OS cannot install the bundle. It can,
however, upgrade to just a newer CPAN.pm; the solution then is to
first install the newer CPAN module, and then that to install the
bundle.

sherm--

Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Tels

2007-07-25 15:53:44 UTC

Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

One "nasty" problem in this particular "port" was the problem I ran
into trying to upgrade the Bundle::CPAN. One pre-requisite was the
Compress package. The 2.x version is somewhat structured differently
from how the 1.x version was organized. The problem happens when I
build/test/install the new version. By default, it goes into my local
"site" library dir, "site_perl". There, it shadows the "Core" version of
Compress.

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

Howeverm, I see that the CPAN version of Compress::Zlib states you should
uninstall the old version manually, instead of setting "installdir
=> 'perl'". I wonder if this is the cause of all the problems and grief
later on (like when the uninstall doesn't uninstall everything).

And even if you manually uninstall the old version, the new should still go
into the core, not "site_perl". Just like f.i. Math::BigInt from CPAN
overwrites (upgrades) the core version, not putting down a second copy into
site_dir.

So, Linda, did you already file a bugreport with the Paul (the author of
Compress::Zlib)?

Or did I miss something?

All the best,

Tels

- --
Signed on Wed Jul 25 17:48:54 2007 with key 0x93B84C15.
Get one of my photo posters: http://bloodgate.com/posters
PGP key on http://bloodgate.com/tels.asc or per email.

"...pornographic images stay in the brain forever." - Mary Anne Layden

"That's a feature, not a bug." - God

Tels

2007-07-25 18:19:19 UTC

Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[snip]

Whoever mains a dual-lived module (e.g. one on CPAN and in the Perl core)
sets up the Makefile.PL so that upon installation the CPAN release will
replace the version already installed in the core. (Otherwise the core
version would still take precedence)

What about "vendor_perl" modules? If modules are in the vendor dir, does
that mean that, when updated, they should update into the vendor dir?

That I don't know.

All the best,

Tels

- --
Signed on Wed Jul 25 20:17:19 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

"Metaphorisch gesprochen war das Trusted-Computing-Vorhaben bisher wie
eine Großmutter, die das Rotkäpchen in ihr Häuschen bitten will und ihm
erklärt, dass die dort vorhandenen Ketten, Handschellen und Kameras zum
Schutz vor dem bösen Wolf dienten und nichts mit ihren belgischen
Geschäftsfreunden zu tun hätten."

-- Peter Mühlbauer 22.02.2004 in http://tinyurl.com/yv6j3

Paul Marquess

2007-07-25 22:40:59 UTC

From: Tels

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[snip]

This is wrong. If Compress is in the core, then the CPAN version

should

overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.
Howeverm, I see that the CPAN version of Compress::Zlib states you
should uninstall the old version manually, instead of setting
"installdir => 'perl'". I wonder if this is the cause of all the
problems and grief later on (like when the uninstall doesn't uninstall
everything).
And even if you manually uninstall the old version, the new should
still go into the core, not "site_perl". Just like f.i. Math::BigInt
from CPAN overwrites (upgrades) the core version, not putting down a
second copy into site_dir.

Why would you want to install it as a core module in this instance? The
system in question is only running perl 5.8.8. C::Zlib isn't a core module
in 5.8.8.

[Before 5.10 ships I will have to address the core/non-core issue, but I
really don't think it is the issue here.]

The reason for the instructions to manually uninstall C::Zlib version 1 is
because the search path for an architecture dependant module comes before an
architecture independent module. C::Zlib version 1 is the former, C::Zlib
version 2 is the latter.

Let me illustrate the problem. Here is what happens if you attempt to
manually install C::Zlib version 2 whilst version 1 is still in place on a
Linux box.

So here is a 588 with C::Zlib 1.42 installed

$ perl588 -MCompress::Zlib -e 'print "$Compress::Zlib::VERSION\n"'
1.42

If I install all the prerequisite modules for C::Zlib version 2, I can build
and test C::Zlib version 2 just fine.

$ make test
...
t/14gzopen......ok
t/99pod.........skipped
all skipped: Test::Pod 1.00 required for testing POD
All tests successful, 1 test skipped.
Files=8, Tests=725, 3 wallclock secs ( 1.94 cusr + 0.35 csys = 2.29
CPU)

And the version of the new C::Zlib is reported as expected with -Mblib

$ perl588 -Mblib -MCompress::Zlib -e 'print "$Compress::Zlib::VERSION\n"'
2.005

So now when I install it we hit a problem

$ make install
...
$ perl588 -MCompress::Zlib -e 'print "$Compress::Zlib::VERSION\n"'
1.42

588 thinks the installed version is still version 1.42!

The problem is the perl search path finds the old C::Zlib in

perl5/site_perl/5.8.8/i686-linux//Compress/Raw/Zlib.pm

before finding the new Zlib.pm in

perl5/site_perl/5.8.8/Compress/Zlib.pm

That though wouldn't explain the problem here - the end result is that you
think you have a new version of C::Zlib, but you still can only get access
to C::Zlib version 1. The old version of C::Zlib should still work.

Paul

Tels

2007-07-26 15:51:30 UTC

Moin,

Post by Paul Marquess
From: Tels

Post by Tels
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.
Howeverm, I see that the CPAN version of Compress::Zlib states you
should uninstall the old version manually, instead of setting
"installdir => 'perl'". I wonder if this is the cause of all the
problems and grief later on (like when the uninstall doesn't
uninstall everything).
And even if you manually uninstall the old version, the new should
still go into the core, not "site_perl". Just like f.i.
Math::BigInt from CPAN overwrites (upgrades) the core version, not
putting down a second copy into site_dir.

Why would you want to install it as a core module in this instance? The
system in question is only running perl 5.8.8. C::Zlib isn't a core
module in 5.8.8.

Ah.

Post by Paul Marquess
[Before 5.10 ships I will have to address the core/non-core issue, but I
really don't think it is the issue here.]
The reason for the instructions to manually uninstall C::Zlib version 1
is because the search path for an architecture dependant module comes
before an architecture independent module. C::Zlib version 1 is the
former, C::Zlib version 2 is the latter.
Let me illustrate the problem. Here is what happens if you attempt to
manually install C::Zlib version 2 whilst version 1 is still in place on
a Linux box.
So here is a 588 with C::Zlib 1.42 installed
$ perl588 -MCompress::Zlib -e 'print "$Compress::Zlib::VERSION\n"'
1.42
If I install all the prerequisite modules for C::Zlib version 2, I can
build and test C::Zlib version 2 just fine.
$ make test
...
t/14gzopen......ok
t/99pod.........skipped
all skipped: Test::Pod 1.00 required for testing POD
All tests successful, 1 test skipped.
Files=8, Tests=725, 3 wallclock secs ( 1.94 cusr + 0.35 csys = 2.29
CPU)
And the version of the new C::Zlib is reported as expected with -Mblib
$ perl588 -Mblib -MCompress::Zlib -e 'print
"$Compress::Zlib::VERSION\n"' 2.005
So now when I install it we hit a problem
$ make install
...
$ perl588 -MCompress::Zlib -e 'print "$Compress::Zlib::VERSION\n"'
1.42
588 thinks the installed version is still version 1.42!
The problem is the perl search path finds the old C::Zlib in
perl5/site_perl/5.8.8/i686-linux//Compress/Raw/Zlib.pm
before finding the new Zlib.pm in
perl5/site_perl/5.8.8/Compress/Zlib.pm
That though wouldn't explain the problem here - the end result is that
you think you have a new version of C::Zlib, but you still can only get
access to C::Zlib version 1. The old version of C::Zlib should still
work.

Thanx for the explanation - I thought the problem was something else.

All the best,

Tels

- --
Signed on Thu Jul 26 17:51:29 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

"A Thaum is the basic unit of magical strength. It has been universally
established as the amount of magic needed to create one small white
pigeon or three normal-sized billiard balls."

-- Terry Pratchett

Linda W

2007-07-25 18:07:59 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

----
No bug reports filed in bug tracking mechanism yet, as I haven't figured
out what is causing what. For example, while I thought it slightly odd that
a Core module would "move itself" from the Core include dirs to the site dirs,
I didn't know that it was a "bug".

How does a module "know" if it is part of the core or not and how does it
"decide" where to install itself?

What about "vendor_perl" modules? If modules are in the vendor dir, does that
mean that, when updated, they should update into the vendor dir?

I.e. -- Is the "rule" to update yourself back to where you were "installed"
(be it "Core" or "Vendor")?

The only error I can confirm (so far) in a clean 5.8.8 install that doesn't
stem from the DLL-upgrade problem, is in Sys::Syslog:
CPAN.pm: Going to build S/SA/SAPER/Sys-Syslog-0.18.tar.gz

WARNING: LICENSE is not a known parameter.
Checking if your kit is complete...
Looks good
'LICENSE' is not a known MakeMaker parameter name.
Writing Makefile for Sys::Syslog
...
t/syslog.......ok 1/159Use of uninitialized value in -w at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 169.
Use of uninitialized value in concatenation (.) or string at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 170.
Use of uninitialized value in -w at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 169.
Use of uninitialized value in concatenation (.) or string at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 170.

# Failed test 'setlogsock() should return true: '''
# in t/syslog.t at line 184.t/syslog.......NOK 136
# Looks like you failed 1 test of 159.
t/syslog.......dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 136
Failed 1/159 tests, 99.37% okay (less 60 skipped tests: 98 okay, 61.64%)

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/syslog.t 1 256 159 1 0.63% 136
3 tests and 66 subtests skipped.
Failed 1/8 test scripts, 87.50% okay. 1/250 subtests failed, 99.60% okay.
make: *** [test_dynamic] Error 1
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force
------------

It seems the Syslog test suite may have some problems -- though I've seen
more than one module (over this whole re-install/rebuild process) that
has issued the "unit value" errors during build or test. This case appears
to point to the Syslog source, however.

L

Linda W

2007-07-25 18:17:10 UTC

Don't know how important this is (one might think no owner would
mean problem isn't likely to be fixed in near future? :-)), but
reported my build/test prob with Sys::Syslog, but the rt system
indicates there is no owner of this module.

Is it part of the base or another module?

L

Jerry D. Hedden

2007-07-25 18:20:48 UTC

Post by Linda W
Don't know how important this is (one might think no owner would
mean problem isn't likely to be fixed in near future? :-)), but
reported my build/test prob with Sys::Syslog, but the rt system
indicates there is no owner of this module.
Is it part of the base or another module?

m***@free.fr

2007-07-26 00:06:45 UTC

Hello,

Sys::Syslog now is a dual-life module, and I am the current CPAN
maintainer.

» http://search.cpan.org/dist/Sys-Syslog/
» https://rt.cpan.org/Dist/Display.html?Queue=Sys-Syslog

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Reini Urban

2007-07-25 21:02:43 UTC

Post by Tels
So, Linda, did you already file a bugreport with the Paul (the author
of Compress::Zlib)?

No, vendor_perl comes with the release only, site_perl is yours to mess
with.
If you do a CPAN update it will update the module into perl, only if it
already exists in perl, otherwise into site_perl. And will therefore
shadow vendor_perl.

I.e. -- Is the "rule" to update yourself back to where you were "installed"
(be it "Core" or "Vendor")?
The only error I can confirm (so far) in a clean 5.8.8 install that doesn't
CPAN.pm: Going to build S/SA/SAPER/Sys-Syslog-0.18.tar.gz
WARNING: LICENSE is not a known parameter.
Checking if your kit is complete...
Looks good
'LICENSE' is not a known MakeMaker parameter name.
Writing Makefile for Sys::Syslog
...
t/syslog.......ok 1/159Use of uninitialized value in -w at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 169.
Use of uninitialized value in concatenation (.) or string at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 170.
Use of uninitialized value in -w at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 169.
Use of uninitialized value in concatenation (.) or string at
/var/cache/CPAN/build/Sys-Syslog-0.18/blib/lib/Sys/Syslog.pm line 170.
# Failed test 'setlogsock() should return true: '''
# in t/syslog.t at line 184.t/syslog.......NOK 136
# Looks like you failed 1 test of 159.
t/syslog.......dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 136
Failed 1/159 tests, 99.37% okay (less 60 skipped tests: 98 okay, 61.64%)
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/syslog.t 1 256 159 1 0.63% 136
3 tests and 66 subtests skipped.
Failed 1/8 test scripts, 87.50% okay. 1/250 subtests failed, 99.60% okay.
make: *** [test_dynamic] Error 1
/usr/bin/make test -- NOT OK
Running make install
make test had returned bad status, won't install without force
------------
It seems the Syslog test suite may have some problems -- though I've seen
more than one module (over this whole re-install/rebuild process) that
has issued the "unit value" errors during build or test. This case appears
to point to the Syslog source, however.

This failing test was fixed by me some weeks ago. Nothing for p5p to
bother about.
See the patch at the Sys::Syslog tracker.
You can also install cygwin syslog-ng, to workaround this, or just
make install without CPAN. Sys::Syslog works with or without the
syslog-ng daemon.

--
Reini

Demerphq

2007-07-25 18:25:58 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

I dont see that that is correct at all. lib/ contains modules that
were bundled with Perl, site/lib contains stuff installed later. Even
if version X of Foo was in lib/ version X+1 should go into site/lib.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Tels

2007-07-25 18:32:48 UTC

Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

One "nasty" problem in this particular "port" was the problem I ran
into trying to upgrade the Bundle::CPAN. One pre-requisite was the
Compress package. The 2.x version is somewhat structured differently
from how the 1.x version was organized. The problem happens when I
build/test/install the new version. By default, it goes into my
local "site" library dir, "site_perl". There, it shadows the "Core"
version of Compress.

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

But if you install Bigint v1.87 into site_lib/lib, then any script will
still use the version from 5.8.8/lib, so your "upgrade" was not doing
anything.

If it is done that way, there would be no point in releasing an updated
version of BigInt to CPAN.

All the best,

Tels

- --
Signed on Wed Jul 25 20:31:53 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

Neulich in Dresden gehört: "Gundach. Schbindadoni. Isvleisch dadidada?"

-- Ex-Kahl-Libur

Jan Dubois

2007-07-25 18:46:25 UTC

Post by Tels

Post by Tels
This is wrong. If Compress is in the core, then the CPAN version
should overwrite the version from core (e.g. "5.8.8/..."), not go
into site_perl.

But if you install Bigint v1.87 into site_lib/lib, then any script
will still use the version from 5.8.8/lib, so your "upgrade" was not
doing anything.

That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed modules
can end up in both?

The root problem of course is that site_lib comes after lib in @INC.

Cheers,
-Jan

PS: For ActivePerl we recently inverted the ordering in @INC to
site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the original
version. :)

Demerphq

2007-07-25 19:05:09 UTC

Post by Tels
This is wrong. If Compress is in the core, then the CPAN version
should overwrite the version from core (e.g. "5.8.8/..."), not go
into site_perl.

But if you install Bigint v1.87 into site_lib/lib, then any script
will still use the version from 5.8.8/lib, so your "upgrade" was not
doing anything.

Tels: this is what UNINST=1 is for.

Post by Jan Dubois
That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed modules
can end up in both?
Cheers,
-Jan
site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the original
version. :)

I like this idea. The only reason I could ever come up with for the
other scheme is security related. You cant override a core module with
using UNINST=1 so therefore you can allow users to install to site/lib
without worrying about scripts that only use core modules being
interfered with. But that sounds kinda weak for a bunch of reasons.

Yves

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Tels

2007-07-25 19:27:14 UTC

Moin,

Post by Tels
This is wrong. If Compress is in the core, then the CPAN version
should overwrite the version from core (e.g. "5.8.8/..."), not go
into site_perl.

I dont see that that is correct at all. lib/ contains modules that
were bundled with Perl, site/lib contains stuff installed later.
Even if version X of Foo was in lib/ version X+1 should go into
site/lib.

But if you install Bigint v1.87 into site_lib/lib, then any script
will still use the version from 5.8.8/lib, so your "upgrade" was not
doing anything.

Tels: this is what UNINST=1 is for.

I think I read a part that that didn't worl (reliable, or at all).

Post by Jan Dubois
That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed
modules can end up in both?
Cheers,
-Jan
site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the original
version. :)

I am not sure I got what you wrote here. :(

All the best,

Tels

- --
Signed on Wed Jul 25 21:26:09 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

"When you don't know what to do, walk fast and look worried."

-- Unknown

Tels

2007-07-25 19:31:55 UTC

Post by Tels
This is wrong. If Compress is in the core, then the CPAN version
should overwrite the version from core (e.g. "5.8.8/..."), not go
into site_perl.

I dont see that that is correct at all. lib/ contains modules that
were bundled with Perl, site/lib contains stuff installed later.
Even if version X of Foo was in lib/ version X+1 should go into
site/lib.

But if you install Bigint v1.87 into site_lib/lib, then any script
will still use the version from 5.8.8/lib, so your "upgrade" was not
doing anything.

Tels: this is what UNINST=1 is for.

(In addition, putting "installdirs => perl" in it will make it work without
instructing the user, etc. So I much prefer it that way. YMMV)

Tels

- --
Signed on Wed Jul 25 21:31:15 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

" ...the Machholz Comet is named after the guy who really discovered it.
Bob Comet."

-- Zathras26 (763537) on 2005-01-01 at /.

Tels

2007-07-25 19:25:58 UTC

Moin,

Post by Tels
This is wrong. If Compress is in the core, then the CPAN version
should overwrite the version from core (e.g. "5.8.8/..."), not go
into site_perl.

But if you install Bigint v1.87 into site_lib/lib, then any script
will still use the version from 5.8.8/lib, so your "upgrade" was not
doing anything.

That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed modules
can end up in both?

Don't ask me, that has been around forever.
I haven't seent that yet as a problem.

Post by Jan Dubois
Cheers,
-Jan
site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the original
version. :)

Why would anyone want this?

I really prefer to have only _ONE_ version of my module in my INC, god knows
what strange bugs and effects you can get when both are there, esp. with
modules that lazyly load other parts and libs. Mixing these versions is
never fun.

But of course, you can do whatever you want on your system or Perl
distribution. I am just writing code and hope someone uses it.

All the best,

Tels

- --
Signed on Wed Jul 25 21:23:49 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

"If Duke Nukem Forever is not out in 2001, something's very wrong."

-- George Broussard, 2001 (http://tinyurl.com/6m8nh)

Andy Dougherty

2007-07-25 20:02:15 UTC

Post by Jan Dubois
That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed modules
can end up in both?

This behavior dates from the times when @INC didn't by default include
earlier versions. It is designed to make it possible to have and use two
different versions of perl installed simultaneously. There's a thorough
discussion of this in 5.005_03's INSTALL file.

Here's a link to a long explanation from an earlier time this subject came
up. (I suspect there are more recent rehashes of the same ideas, but I
don't think anyone (including myself) has actually done anything.)

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-04/msg02380.html

--
Andy Dougherty ***@lafayette.edu

Jan Dubois

2007-07-26 00:17:31 UTC

Post by Andy Dougherty

Post by Jan Dubois
That is all true, but isn't this really backwards? What is the point
of having a separate lib and site_lib directory if site installed modules
can end up in both?

earlier versions. It is designed to make it possible to have and use two
different versions of perl installed simultaneously. There's a thorough
discussion of this in 5.005_03's INSTALL file.
Here's a link to a long explanation from an earlier time this subject came
up. (I suspect there are more recent rehashes of the same ideas, but I
don't think anyone (including myself) has actually done anything.)
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-04/msg02380.html

I would like to challenge the need to keep all these complex setup options.
There have been good reasons for them in the past, but I think nowadays they
are obsolete, except _maybe_ for a few perl5-porters. But the requirement to
keep all these options working essentially prohibits everyone from making any
changes (it is not just core Perl and Configure, but also MakeMaker that may
need to be updated).

I can send a patch that allows uses -Accflags=-DPRIVLIB_LAST_IN_INC to
reverse the ordering in @INC. But it may only be useful when used with
-Dinc_version_list=none.

Cheers,
-Jan

Rafael Garcia-Suarez

2007-07-26 09:02:43 UTC

Post by Jan Dubois
I would like to challenge the need to keep all these complex setup options.
There have been good reasons for them in the past, but I think nowadays they
are obsolete, except _maybe_ for a few perl5-porters. But the requirement to
keep all these options working essentially prohibits everyone from making any
changes (it is not just core Perl and Configure, but also MakeMaker that may
need to be updated).
I can send a patch that allows uses -Accflags=-DPRIVLIB_LAST_IN_INC to
-Dinc_version_list=none.

I think that there's some need to rethink that, with in mind both the
needs of people who package perl for OSes, and those who recompile
them for their own use and deployment. Package management systems are
more commonly used nowadays than they were (and that's why
installusrbinperl is no longer the default).

However I prefer to take some time to think about all the implications
(and look at how the vendors do it). For 5.10, a patch entirely
contained in #ifdefs is fine, but a better solution (for the next
perl) might not be entirely compatible with this one.

H.Merijn Brand

2007-07-26 09:34:18 UTC

Post by Rafael Garcia-Suarez

On Thu, 26 Jul 2007 11:02:43 +0200, "Rafael Garcia-Suarez"

Isn't this where vendorprefix is useful? They could reorder @INC to their
hearts consent

Post by Rafael Garcia-Suarez
However I prefer to take some time to think about all the implications
(and look at how the vendors do it). For 5.10, a patch entirely
contained in #ifdefs is fine, but a better solution (for the next
perl) might not be entirely compatible with this one.

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/

m***@free.fr

2007-07-26 00:38:17 UTC

Post by Jan Dubois
site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the original
version. :)

/me puts his "dual-life module maintainer" hat

Does this means that we should now *not* set INSTALLDIRS to "perl"
when the modules are being installed on ActivePerl (past a given
build number)? Because AFAICT, all dual-life modules are currently
installed this way (at least, the two core modules I maintain are).

Side question: how do we detect that we're running under ActivePerl?
(and how do we get the build number?)

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Jan Dubois

2007-07-26 00:58:35 UTC

Post by m***@free.fr

site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the
original version. :)

/me puts his "dual-life module maintainer" hat
Does this means that we should now *not* set INSTALLDIRS to "perl"
when the modules are being installed on ActivePerl (past a given build
number)? Because AFAICT, all dual-life modules are currently installed
this way (at least, the two core modules I maintain are).

I think it would be better to modify MakeMaker to redirect INSTALLDIRS
"perl" to "site" when Perl has been built with -DPRIVLIB_LAST_IN_INC.
That way all the other distributions that have changed @INC order would
benefit from it too, and we won't need any changes to released CPAN modules.

This change is not urgent though; installing into "perl" continues to work
so long as you don't install a copy of the module into "site" as well.
You just don't get the benefit of being able to revert to the original
version.

Post by m***@free.fr
Side question: how do we detect that we're running under ActivePerl?
(and how do we get the build number?)

On Windows there has "always" been a Win32::BuildNumber() function, but
for cross-platform support you should use ActivePerl::BUILD(). The
latter has been introduced only recently (build 814).

Cheers,
-Jan

m***@free.fr

2007-07-26 01:33:33 UTC

Post by Jan Dubois

Post by m***@free.fr

site_lib, vendor_lib, and lib. Installing new versions of core
modules into site_lib makes it much easier to revert to the
original version. :)

/me puts his "dual-life module maintainer" hat
Does this means that we should now *not* set INSTALLDIRS to "perl"
when the modules are being installed on ActivePerl (past a given build
number)? Because AFAICT, all dual-life modules are currently
installed
this way (at least, the two core modules I maintain are).

I think it would be better to modify MakeMaker to redirect INSTALLDIRS
"perl" to "site" when Perl has been built with -DPRIVLIB_LAST_IN_INC.
benefit from it too, and we won't need any changes to released CPAN modules.
This change is not urgent though; installing into "perl" continues to work
so long as you don't install a copy of the module into "site" as well.
You just don't get the benefit of being able to revert to the original
version.

Well, if this is as simple as

push @params, INSTALLDIRS => "perl"
unless $Config{ccflags} =~ /-DPRIVLIB_LAST_IN_INC/;
WriteMakefile(..., @params);

it may be worth adding it in order to benefit from this feature.

Post by Jan Dubois

Post by m***@free.fr
Side question: how do we detect that we're running under ActivePerl?
(and how do we get the build number?)

On Windows there has "always" been a Win32::BuildNumber() function, but
for cross-platform support you should use ActivePerl::BUILD(). The
latter has been introduced only recently (build 814).

Thanks. Just found the documentation of the ActivePerl and
ActiveState::* modules.
I note that the page for Sys::Syslog is missing though.

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Sherm Pendley

2007-07-25 20:30:45 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

One "nasty" problem in this particular "port" was the problem I ran
into trying to upgrade the Bundle::CPAN. One pre-requisite was the
Compress package. The 2.x version is somewhat structured
differently
from how the 1.x version was organized. The problem happens when I
build/test/install the new version. By default, it goes into my
local "site" library dir, "site_perl". There, it shadows the "Core"
version of Compress.

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

But if you install Bigint v1.87 into site_lib/lib, then any script will
still use the version from 5.8.8/lib, so your "upgrade" was not doing
anything.

If that's not what you want, just use UNINST=1 to prevent it from
happening. CPAN.pm will then delete the old version from lib after
installing the new one in site_lib.

sherm--

Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Tels

2007-07-25 21:02:07 UTC

Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[snip]

Post by Demerphq
I dont see that that is correct at all. lib/ contains modules that
were bundled with Perl, site/lib contains stuff installed later. Even
if version X of Foo was in lib/ version X+1 should go into site/lib.

But if you install Bigint v1.87 into site_lib/lib, then any script will
still use the version from 5.8.8/lib, so your "upgrade" was not doing
anything.

If that's not what you want, just use UNINST=1 to prevent it from
happening. CPAN.pm will then delete the old version from lib after
installing the new one in site_lib.

# perl Makefile.PL UNINST=1
include /home/te/perl/math/Math-BigInt-1.88/inc/Module/Install.pm
include inc/Module/Install/Metadata.pm
include inc/Module/Install/Base.pm
include inc/Module/Install/WriteAll.pm
Writing META.yml
include inc/Module/Install/Makefile.pm
include inc/Module/Install/Win32.pm
include inc/Module/Install/Can.pm
include inc/Module/Install/Fetch.pm
'UNINST' is not a known MakeMaker parameter name.
Writing Makefile for Math::BigInt
#

I am afraid that doesn't work :)

All the best,

Tels

- --
Signed on Wed Jul 25 23:01:13 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.

"Call me Justin, Justin Case."

Sherm Pendley

2007-07-25 22:16:14 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[snip]

But if you install Bigint v1.87 into site_lib/lib, then any script will
still use the version from 5.8.8/lib, so your "upgrade" was not doing
anything.

If that's not what you want, just use UNINST=1 to prevent it from
happening. CPAN.pm will then delete the old version from lib after
installing the new one in site_lib.

It works when you use it correctly. It's an argument to "make
install", not to "Makefile.PL".

sherm--

Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Andy Dougherty

2007-07-25 19:39:14 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

I'm afraid that won't work in a standard install because the site
library directories are searched *after* the core directories. Thus
version X would still be found, and version X+1 wouldn't.

--
Andy Dougherty ***@lafayette.edu

Demerphq

2007-07-25 19:59:22 UTC

Post by Andy Dougherty

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Moin,
[skipping everythig else]

On Tue, 24 Jul 2007 13:50:13 -0700, Linda W

This is wrong. If Compress is in the core, then the CPAN version should
overwrite the version from core (e.g. "5.8.8/..."), not go into site_perl.

I'm afraid that won't work in a standard install because the site
library directories are searched *after* the core directories. Thus
version X would still be found, and version X+1 wouldn't.

Yes, which is why we have UNINST=1.

Which explains my point about the current scheme being secure. If i
restrict access to lib but allow free access to site/lib I know that
any code which depends only on modules in lib to actually end up
running only modules in lib. You cant booby trap a system by putting a
warnings.pm in site/lib that does something nasty.

And im just curious but what happens when somebody wants to use PREFIX
with a module that wants to install into lib? (No i dont know that it
does something dumb, its a real question :-)

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Johan Vromans

2007-07-26 08:05:10 UTC