Re: Perl 5.005.02

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

Roderick Schertler, in an immanent manifestation of deity, wrote:
>I don't think Andy is taking into account your plan of allowing both
>threaded and non-threaded Perls present on the system at the same time.

That's okay since a) threaded Perl has it's own architecture b)
experimental Perl releases will be in a completely different directory.


>It seems to me that the only real problem we've got with the current
>layout is that the *.pm files for extensions which have XS portions are
>placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.

It used to do that before 5.004 I think.  It doesn't do that anymore.  I 
had to fix perl-base's list of file to deal with this...

>Further, if the  part of that didn't necessarily track
>every new version, but only changed when a new version was binary
>incompatible, that would save even more recompilation.  That is, if

Hmm.  Maybe but that might be too dangerous.

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNiWEpY4wrq++1Ls5AQH5owP/dpatyU9ZSiN60gWq3SSq7zFhXjmcWcmH
G8EwruuDMJKUIQCIuNE/nbzO0eoSlFTS944HV0h0ww7IWbzxk7VMZDx2Z2oy31hf
KfIM6fcNH6zGEgvXe1fUVuvFv300X5nffuQKCywvob3vswR1m+C2rxrDueb3mhmz
jybFZ/W9PEQ=
=tRkI
-END PGP SIGNATURE-

Re: Perl 5.005.02

[John Lapeyre]

Re: installing perl
There is a problem, which is detailed below. I just used
--force-overwrite to get around it.

homey 3 > ls *.deb
perl-base_5.005.02-1_i386.deb  perl_5.005.02-1_i386.deb
homey 4 > dpkg -i *.deb
(Reading database ... 60093 files and directories currently installed.)
Preparing to replace perl-base 5.004.04-6 (using
perl-base_5.005.02-1_i386.deb)
...
Unpacking replacement perl-base ...
Preparing to replace perl 5.004.04-6 (using perl_5.005.02-1_i386.deb) ...
Unpacking replacement perl ...
dpkg: error processing perl_5.005.02-1_i386.deb (--install):
 trying to overwrite `/usr/man/man3/Data::Dumper.3pm.gz', which is also in
packa   
ge data-dumper
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Setting up perl-base (5.005.02-1) ...

Errors were encountered while processing:
 perl_5.005.02-1_i386.deb


John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Perl 5.005.02

[Christopher C. Chimelis]

Raphael Hertzog wrote:
> 
> The perl package is in incoming. So here is the list of the 33 packages that
> need to be updated. The maintainers are listed. The list corresponds to
> package which contains filenames matching "/usr/lib/perl5.*\.so".

FYI, this package doesn't build properly on the Alpha (fails several
tests including regex).  I'll look further into it, but expect a bug
report and/or patch :-)  (a little forewarning)...

C

Re: Perl 5.005.02

[John Lapeyre]

The new perl breaks all my perl-module packages. How badly I don't
know yet. I expected this because I see how the pdl developers scramble to
keep up with new releases of perl.
It can probably be sorted out, but it will take some effort from
all who have perl-module-related packages .
One problem is the new perl version is storing files in different
places.  So modules will have to be debugged to remove hard-wired
references to the old paths.
On the other hand, pdl , which is a large and sophisticated
"module",  works OK for the most part, although some path-related bugs are
introduced.
John




John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Perl 5.005.02

[Raphael Hertzog]

Le Tue, Oct 06, 1998 at 01:35:46PM +0200, Raphael Hertzog écrivait:
> The perl package is in incoming. So here is the list of the 33 packages that 

Well it doesn't work out of the box as I expected it. First the
@INC isn't correct, it doesn't contain /usr/lib/perl5. Please
Darren can you correct it ?

Nevertheless I tried to recompile my lib*perl modules and second problem
comes to me : dpkg-shlibdeps seems no to work anymore (in fact the launch
is ok but it fails to do what it should (set debian/substvars))... I'm
looking why ... maybe just a directory problem too.

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: Perl 5.005.02

[Raphael Hertzog]

Le Tue, Oct 06, 1998 at 10:56:28PM +0200, Raphael Hertzog écrivait:
> Nevertheless I tried to recompile my lib*perl modules and second problem
> comes to me : dpkg-shlibdeps seems no to work anymore (in fact the launch
> is ok but it fails to do what it should (set debian/substvars))... I'm
> looking why ... maybe just a directory problem too.

Sorry I found the problem. dpkg-shlibdeps has no problem but in fact
this a changed :

$ ldd /usr/lib/perl5/i386-linux/5.004/auto/Locale/Msgcat/Msgcat.so
libc.so.6 => /lib/libc.so.6 (0x40006000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x)
$ ldd /rack/perso/travaux/...5.005.../Msgcat.so
statically linked

That's why the substitution ${shlibs:Depends} failed and stopped the
package building. So just correct your control file...

And wait for a new perl package so that *.pm file will install themselves
in /usr/lib/perl5 instead of /usr/lib/perl5/5.005.

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: Perl 5.005.02

[Stephen Zander]

> "Raphael" == Raphael Hertzog <[EMAIL PROTECTED]> writes:

Raphael> Hello everybody, The perl package is in incoming. So here
Raphael> is the list of the 33 packages that need to be
Raphael> updated. The maintainers are listed. The list corresponds
Raphael> to package which contains filenames matching
Raphael> "/usr/lib/perl5.*\.so".

Just for my own curiousity: did Darren build this package or is it an
NMU?

Raphael> interpreters/perl-tk   Rob Browning <[EMAIL PROTECTED]>

You need to download a more up-to-date Packages files.  Rob doesn't
own that package, I do.

-- 
Stephen
---
Perl is really designed more for the guys that will hack Perl at least
20 minutes a day for the rest of their career.  TCL/Python is more a
"20 minutes a week", and VB is probably in that "20 minutes a month"
group. :) -- Randal Schwartz

Re: Perl 5.005.02

[Raphael Hertzog]

Le Tue, Oct 06, 1998 at 02:22:50PM -0700, Stephen Zander écrivait:
> Just for my own curiousity: did Darren build this package or is it an
> NMU?

It's Darren. I would have never done a NMU without Darren's approval and
without the consent of the ML.

> You need to download a more up-to-date Packages files.  Rob doesn't
> own that package, I do.

I downloaded it 2 days ago on ftp.de.debian.org ... it's probably
the only error.

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: Perl 5.005.02

[John Lapeyre]

On Tue, 6 Oct 1998, Raphael Hertzog wrote:
rhertz>And wait for a new perl package so that *.pm file will install themselves
rhertz>in /usr/lib/perl5 instead of /usr/lib/perl5/5.005.

O, I thought it was perhaps intentional. Could you please notify
this list when you upload the new package ?  Thanks.

John

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Perl 5.005.02

[Bart Schuller]

On Tue, Oct 06, 1998 at 01:35:46PM +0200, Raphael Hertzog wrote:
> The perl package is in incoming. So here is the list of the 33 packages that 
> need to be updated. The maintainers are listed. The list corresponds to
> package which contains filenames matching "/usr/lib/perl5.*\.so".

This didn't catch vim-perl, which seems to have been statically linked
to perl, but references the libraries of the current version so should
be upgraded as well.

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]

Re: Perl 5.005.02

[John Lapeyre]

On Tue, 6 Oct 1998, Raphael Hertzog wrote:

rhertz>Well it doesn't work out of the box as I expected it. First the
rhertz>@INC isn't correct, it doesn't contain /usr/lib/perl5. Please
rhertz>Darren can you correct it ?

I downloaded the upstream source. It looks like the omission of
/usr/lib/perl5 in @INC  was intentional.

>From INSTALL:
=head1 Coexistence with earlier versions of perl5

WARNING:  The upgrade from 5.004_0x to 5.005 is going to be a bit
tricky.  See L<"Upgrading from 5.004 to 5.005">  below.

Re: Perl 5.005.02

[Raphael Hertzog]

Le Tue, Oct 06, 1998 at 06:02:18PM -0700, John Lapeyre écrivait:
>   I downloaded the upstream source. It looks like the omission of
> /usr/lib/perl5 in @INC  was intentional.

You're right. But this does mean that all packages installing *.pm
files need to be updated. It does also mean that we will have the same 
problem with perl-5.006 ... we surely a need a better way to handle
this.

The INSTALL file suggest to keep /usr/bin/perl5.00404 so that
programs using old modules will still work. But in fact coexistence
for Debian is not as easy as that. The INSTALL file suppose that modules
are installed manually (eg. with perl -MCPAN -e shell) and that
when installing new modules, the older ones will stay in the old
directory. This is not the case for Debian because when upgrading
a package the old files are removed.

Any idea how to handle this properly ? Maybe we need a sort of perl
policy : package will have to install file under /usr/lib/perl5/debian
which would be a symlink to the current perl version ? But
this does not solve all problems... Better idea ?

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

Re: Perl 5.005.02

[Wichert Akkerman]

Previously Bart Schuller wrote:
> This didn't catch vim-perl, which seems to have been statically linked
> to perl, but references the libraries of the current version so should
> be upgraded as well.

It is, since vim's configure couldn't find any shared-libraries for perl.
And from what I see I don't have any installed either.

I'll recompile vim tomorrow or tonight with the new perl.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpGrDGUFdvgB.pgp
Description: PGP signature

Re: Perl 5.005.02

[Andy Dougherty]

[ perl5.005_02's default library is now /usr/lib/perl5/perl5.005,
  and might change with 5.006, etc.]

> Any idea how to handle this properly ? Maybe we need a sort of perl
> policy : package will have to install file under /usr/lib/perl5/debian
> which would be a symlink to the current perl version ? But
> this does not solve all problems... Better idea ?

Yes.  Perl itself knows where it is installed.  Install .pm things into
$Config{'privlib'}.  From the shell command line, you can get this
same information with /usr/bin/perl -V:privlib.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Perl 5.005.02

[Andy Dougherty]

On Fri, 9 Oct 1998, Andy Dougherty wrote:

> [ perl5.005_02's default library is now /usr/lib/perl5/perl5.005,
>   and might change with 5.006, etc.]
> 
> > Any idea how to handle this properly ? Maybe we need a sort of perl
> > policy : package will have to install file under /usr/lib/perl5/debian
> > which would be a symlink to the current perl version ? But
> > this does not solve all problems... Better idea ?

After some thought, I think I'd recommend that perl5.005_xx retain the
same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
5.00[34], of course).

Perl's default directory structure is designed to accomodate the
simultaneous installation of more than one perl version.  Since Debian
doesn't do that, there's no reason to put versions in separate
version-specific directories.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Perl 5.005.02

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

Andy Dougherty, in an immanent manifestation of deity, wrote:
>After some thought, I think I'd recommend that perl5.005_xx retain the
>same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
>5.00[34], of course).

That's good enough for me.  I have boatloads of respect for Andy and his 
understanding of Perl Install issues.  That's how it will be for
5.005.02-3.

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNiCDlY4wrq++1Ls5AQFRmQQAopbz9/JQ0qB1n2kUHYvKJybYMaZDuYGP
S2ibIg/SE3tmizhkw/V9mAY79Bqp3EboYSfwuWd2/lPGVHR4WBxBV2vqTMqvhCyk
kDHz+/ulYsDMxwS04nSzh6+wz3U9V35oX6UpXOlKeDjxKDblw2D+wmxd21TQ35WN
Pyk6dsWhMBQ=
=eq3P
-END PGP SIGNATURE-

Re: Perl 5.005.02

[Roderick Schertler]

On 11 Oct 1998 03:08:22 -0700, "Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> 
said:
> Andy Dougherty, in an immanent manifestation of deity, wrote:
>>
>> After some thought, I think I'd recommend that perl5.005_xx retain the
>> same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
>> 5.00[34], of course).
>
> That's good enough for me.  I have boatloads of respect for Andy and his
> understanding of Perl Install issues.  That's how it will be for
> 5.005.02-3.

I don't think Andy is taking into account your plan of allowing both
threaded and non-threaded Perls present on the system at the same time.

It seems to me that the only real problem we've got with the current
layout is that the *.pm files for extensions which have XS portions are
placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.
If that were changed so that such modules behaved like core modules
(placing both *.pm and *.so in the arch/version hierarchy) then only
modules with *.so files would need to be reinstalled when a new version
is installed.  If this were in place previously then the recent 5.005
install would only have broken modules with XS portions, as it should
have.

Further, if the  part of that didn't necessarily track
every new version, but only changed when a new version was binary
incompatible, that would save even more recompilation.  That is, if
5.006 doesn't break binary compatibility, I'd recommend that you
continue to use /usr/lib/perl5//5.005 rather than changing to
/usr/lib/perl5//perl5.006.

-- 
Roderick Schertler
[EMAIL PROTECTED]

Re: Perl 5.005.02

[warp]

On Sun, Oct 11, 1998 at 11:28:06AM -0400, Roderick Schertler wrote:
> On 11 Oct 1998 03:08:22 -0700, "Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> 
> said:
> > Andy Dougherty, in an immanent manifestation of deity, wrote:
> >>
> >> After some thought, I think I'd recommend that perl5.005_xx retain the
> >> same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
> >> 5.00[34], of course).
> >
> > That's good enough for me.  I have boatloads of respect for Andy and his
> > understanding of Perl Install issues.  That's how it will be for
> > 5.005.02-3.
> 
> I don't think Andy is taking into account your plan of allowing both
> threaded and non-threaded Perls present on the system at the same time.
> 
> It seems to me that the only real problem we've got with the current
> layout is that the *.pm files for extensions which have XS portions are
> placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.
> If that were changed so that such modules behaved like core modules
> (placing both *.pm and *.so in the arch/version hierarchy) then only
> modules with *.so files would need to be reinstalled when a new version
> is installed.  If this were in place previously then the recent 5.005
> install would only have broken modules with XS portions, as it should
> have.
> 
> Further, if the  part of that didn't necessarily track
> every new version, but only changed when a new version was binary
> incompatible, that would save even more recompilation.  That is, if
> 5.006 doesn't break binary compatibility, I'd recommend that you
> continue to use /usr/lib/perl5//5.005 rather than changing to
> /usr/lib/perl5//perl5.006.

I would suggest using symlinks here, have the version be the first one
which was binary compatible with all binarys there, and then for the
rest just symlink the new version dirs to the old until binary
compatibility is broken..

Also, when possible, could we try to lean towards having support for
more then one version of perl installed at the same time even if
currently its not possible?

(See my preavous posts on perl on a possible way to allow having more
then one installed at the same time)

Zephaniah E, Hull.
> 
> -- 
> Roderick Schertler
> [EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpnu47V19lyT.pgp
Description: PGP signature

Re: Perl 5.005.02

[cfm]

My $.02 on this - and this is only personal feedback-
is that perl -MCPAN -e shell is even easier than 
apt-get.  So I maintain a perl5.tgz with our
various modules from CPAN already installed and whenever
debian blows away our perl on any particular machine we
just unpack it from our local distribution tree, maybe updating
with a new DebianNet.pm or some such.  What I would prefer is
perl -MCPAN -e shell  and  install Bundle::Debian.  I'm **almost**
tempted to bite on that too ;^)

> > > That's good enough for me.  I have boatloads of respect for Andy and his
> > > understanding of Perl Install issues.  That's how it will be for
> > > 5.005.02-3.

For better or worse, if the perl developers chose this new structure
for 5.005, then the decision to deviate incurs a huge cost, 
particularly when one considers the snowball effect and the 
costs of realignment in the future.

Best,

cfm

-- 

Christopher F. Miller, Publisher[EMAIL PROTECTED]
MaineStreet Communications, Inc208 Portland Road, Gray, ME  04039
1.207.657.5078  (MTRF 3-5pm)http://www.maine.com/

Re: Perl 5.005.02

[John Lapeyre]

On 11 Oct 1998, Darren/Torin/Who Ever... wrote:

torin>Andy Dougherty, in an immanent manifestation of deity, wrote:
torin>>After some thought, I think I'd recommend that perl5.005_xx retain the
torin>>same directory structure that perl5.00[34]_xx did. (with 5.005 in place 
of
torin>>5.00[34], of course).
torin>
torin>That's good enough for me.  I have boatloads of respect for Andy and his 
torin>understanding of Perl Install issues.  That's how it will be for
torin>5.005.02-3.

Good, I think that will cause the least problems for the rest of
Debian.
John


John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Perl 5.005.02

[Andy Dougherty]

On Sun, Oct 11, 1998 at 11:28:06AM -0400, Roderick Schertler wrote:

> > Andy Dougherty, in an immanent manifestation of deity, wrote:
> >>
> >> After some thought, I think I'd recommend that perl5.005_xx retain the
> >> same directory structure that perl5.00[34]_xx did. (with 5.005 in place of
> >> 5.00[34], of course).

> I don't think Andy is taking into account your plan of allowing both
> threaded and non-threaded Perls present on the system at the same time.

That shouldn't matter, since the threaded version ought to have it's
own $Config{'archname'} and put all the thread-specific files in something
vaguely like /usr/lib/perl5/i386-linux-thread (Configure handles this
automatically).  The threaded and non-threaded versions can share the rest
of the files.  (Well, there can be only one /usr/bin/perl, of course:-).
I don't know how to tell dpkg that such files are shared, however.

If, however, Debian does move towards supporting simultaneous installation
of multiple perl versions, then I think the new 5.005 default directory
structure still won't be rich enough.  In that case, Debian probably ought
to introduce a new set of directories--perhaps call them $vendor_arch and
$vendor_lib--to hold Debian-supplied extensions and modules.  These would
work just like the /usr/local/lib/site* variables (in how they track
changes in perl versions) but they would be in the /usr/lib/ hierarchy for
Debian to use.

> It seems to me that the only real problem we've got with the current
> layout is that the *.pm files for extensions which have XS portions are
> placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.

I thought MakeMaker was supposed to do that automatically already.  I'd
consider that a MakeMaker bug.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042