Re: Perl policy for managing modules ?
Hi, Raphael == Raphael Hertzog [EMAIL PROTECTED] writes: Raphael Le Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz écrivait: My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand Raphael Because most of the perl modules will work with all coming Raphael version of perl. I guess I am confused. How do we know this? How can we be certain that there shall not be any further binary incompatibilities introduced in Perl? The fact that the upstream releases are maintianing the versioned component seems to imply that no such (implied) promise has been made by the perl 5 porters group. Raphael Because Debian doesn't allow different version of the same Raphael package to be on the same machine. Hmm. The statement is indeed true, I just seem to be too dense to see how it applies. Say the new Perl (released in jan 1999, say) is binary incompatible to 5.005. I have a module, foo. How does this scheme prevent a recompilation then? Are we just putting all our eggs in the basket that despite the record, there shall never be any incompatible perl releases? Raphael Because we don't want to have to update the packages that Raphael contains modules each time a new perl version comes out. This, I agree with. The solution proposed either is a kludge, or I am missing the point. Me, I would create the current and all future versions of Perl which are binary compatible to have the link: /usr/lib/perl5/$arch/$version -- /usr/lib/perl5/$arch/code name No modules need be recompiled when the new perl comes out, since all of them really reside in code name dir. When a new incompatible Perl comes out, we change the code name, and recompile. What am I missing? manoj -- When you meet a master swordsman, show him your sword. When you meet a man who is not a poet, do not show him your poem. Rinzai, ninth century Zen master Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Perl policy for managing modules ?
On 11 Oct 1998 21:14:40 -0500, Manoj Srivastava [EMAIL PROTECTED] said: Raphael == Raphael Hertzog [EMAIL PROTECTED] writes: Because most of the perl modules will work with all coming version of perl. I guess I am confused. How do we know this? How can we be certain that there shall not be any further binary incompatibilities introduced in Perl? I believe he's talking about Perl modules without XS (or other non-Perl) components. These aren't affected by changes in binary compatibility. Compiled modules would still go into a versioned directory (using, I hope, a scheme which really tracks binary compatibility rather than Perl version numbers, as you describe). -- Roderick Schertler [EMAIL PROTECTED]
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Zephaniah E. Hull, in an immanent manifestation of deity, wrote: Rename perl to perl5.005, version 02-2 or such.. Then use the alternatives setup to decide which perl gets run when you try to use just 'perl'.. That's possible but I'm not sure it's a good idea. It seems a hard thing to get right. I notice that x?emacs and java constantly have problems with their alternatives. Also, would perl-base be an alternative? I do plan on releasing versioned packages but those would be for specific needs and not the general case. There's the idea from Carey Evans [EMAIL PROTECTED] where a Perl can put Provides: perl5.005 in the control file. Hopefully it's okay to discuss this here even though it's a policy sort of discussion. I don't have time to read debian-policy. (What is the traffic there like?) Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [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 iQCVAwUBNh9ANY4wrq++1Ls5AQEvCwP/SEViUd8G6+W6C252uQMdQlAB4H6OHnvX UWaqDhyMwSnMNRN4nZ+PRt/v24ISuU76s8MiMLrF18Cd2CVV9vZqJjuOIEMakWir FmnEjgjZGop6RZ8hzv1StEHPAhnXBmoflLOjoBHLksHVoxEbCH5+VT8QN11fFXKe k2Jzhvn23ao= =H8vx -END PGP SIGNATURE-
Re: Perl policy for managing modules ?
Ok, after some thought, and fielding a LOT of perl questions on #debian, I've come up with a more workable idea which gives us much better handling for the next time something like this happens.. Rename perl to perl5.005, version 02-2 or such.. Then use the alternatives setup to decide which perl gets run when you try to use just 'perl'.. At that point packages which are NOT subject to binary compatibility issues can depend on perl5, and those which are can depend on perl5.005, etc.. This allows us to both handle future perl upgrades cleanly, and allows us to maintain more then one version of perl at any given time.. Any comments? Zephaniah E, Hull.. On Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz wrote: Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpk4oO1Le4IK.pgp Description: PGP signature
Re: Perl policy for managing modules ?
On Wed, 7 Oct 1998, Raphael Hertzog wrote: rhertzI propose to make package install the modules in /usr/lib/perl5/debian rhertzand /usr/lib/perl5/debian/$arch. And the /usr/lib/perl5/$version would rhertzbe a link to debian, and /usr/lib/perl5/$arch/$version a link to rhertz../debian/$arch. So the current perl will always find the modules rhertzinstalled. And we'll have no problem for the transition to perl5.006 ... rhertz rhertzHow to manage this in the source package for a CPAN module ? Here's rhertzwhat I would have to do for my own package (I tested it) : rhertz rhertz- use this line for creating the Makefile : rhertz perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian rhertz- and use make pure_install for installing files Thats how I build my perl modules as well (and I guess others), so it shouldn't be too much of a problem. (Acutally some of the more complicated packages will need more changes.) I can't think of a better solution. Re: packages with only perl source, many will probably not be affected by an upgrade, and it seems silly to require that they be rebuilt. I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Perl policy for managing modules ?
Le Wed, Oct 07, 1998 at 04:16:09PM -0700, John Lapeyre écrivait: Thats how I build my perl modules as well (and I guess others), so it shouldn't be too much of a problem. (Acutally some of the more complicated packages will need more changes.) Yes I've looked over source for packages that need to work on my own machine and it was really not hard for upgrading. I had some problems for installing file where I wanted but in fact this should work on most cases : - perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian - but for installing the PREFIX variable is also needed : make pure_install PREFIX=`pwd`/debian/tmp/usr = adapt it for your own package Darren, if you agree, can you modify the perl package in order to install modules in /usr/lib/perl5/debian and make these symlinks ? - /usr/lib/perl5/$arch/$version = /usr/lib/perl5/debian/$arch - /usr/lib/perl5/$version = /usr/lib/perl5/debian I can't think of a better solution. Re: packages with only perl source, many will probably not be affected by an upgrade, and it seems silly to require that they be rebuilt. Yes. I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) Yes, and I wondered why I was the only one who worried about that. :) And it's difficult to move backward since some packages has already been upgraded for perl5.005. Summary: - all packages installing perl modules are broken, they need to be updated using the directory proposed before. (/usr/lib/perl5/debian) There will be NO perl5.005 package using /usr/lib/perl5 for searching modules. - the perl package need to be updated in order to make it work - In fact I don't know if I really should list packages installing modules right now and fill bug report because there are too many (80), I'll wait a few days I think. Richard Braakman asked me for updating lintian so maybe he will be able to fill the bugreports automatically in a few days. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: Darren, if you agree, can you modify the perl package in order to install modules in /usr/lib/perl5/debian and make these symlinks ? - /usr/lib/perl5/$arch/$version = /usr/lib/perl5/debian/$arch - /usr/lib/perl5/$version = /usr/lib/perl5/debian Okay. That's relatively easy. I can just change privlib and archlib to the directories and put in symlinks. I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. Please lets have a decision on this soon. I've uploaded a new version of Perl right now to fix the data-dumper problem. BTW, the reason that this doesn't affect many people on p5p is that non-core modules are usually installed someplace outside of the Perl tree. INSTALLDIRS=perl is usually only used for the core. John Lapeyre, in an immanent manifestation of deity, wrote: I posted a message on perl5-porters asking for advice. We need to set a policy quickly, as quite a bit of slink has just become unstable. (Unfortunatley, I was using slink for daily science work. I don't have two machines.) Sorry about that. It is called unstable because things break sometimes. Even on my development box, I watch debian-bugs to see if disastrous things happen. I'm still worried about libc6 2.0.7u-1. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [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 iQCVAwUBNhyGe44wrq++1Ls5AQETHwP/ZyKbtc/4W4AHh+m/7P63wbr2HiJ5Uivq FtHCkJO7oeMKiDgMTw79PYtkUnKdxj8wsVr8busVav07QXOd7KYA36hfS3A80mi0 i4O9PVv2Akt/h9byFNU31jEMHLe73O00szpCuS28nRkG5wsngMskNtZWJGJOa1/t FpvwZiTv7go= =++nM -END PGP SIGNATURE-
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. Yes it should work too. Please lets have a decision on this soon. Both solutions are OK for me, choose the best (at your opinion, of course). :) BTW, the reason that this doesn't affect many people on p5p is that non-core modules are usually installed someplace outside of the Perl tree. INSTALLDIRS=perl is usually only used for the core. Yes, but it's better leaving site_perl empty. It can be used for manually (modules not in a .deb file) installing modules. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Dan
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: I do worry about what this might break as well. Another option would be to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and leave /usr/lib/perl5/$version(/$arch)? there with only the Perl installed files. I'll ask on p5p if this will break things. What about also adding /usr/lib/perl5(/$arch)? at the end of @INC ? Is it possible ? In that way, recent packages that are installed in /usr/lib/perl5/debian are used first and only if no package is found in the standard path then perl will search for modules in /usr/lib/perl5. If we can do it, I think that's the best solution in order no to break non architecture dependent packages that already exists. That way there will never be any problem with DebianNet.pm and other modules. And we also can move slowly to a unified directory tree. Otherwise the transition seems to be too difficult. I hope this can solve our current problem (and by the way make it include in slink). Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Perl policy for managing modules ?
Le Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz écrivait: My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand Because most of the perl modules will work with all coming version of perl. Because Debian doesn't allow different version of the same package to be on the same machine. Because we don't want to have to update the packages that contains modules each time a new perl version comes out. that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Explain more here, how would you manage a versioned directory without changing the modules packages each time a new perl version comes out ? Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: Yes, but it's better leaving site_perl empty. It can be used for manually (modules not in a .deb file) installing modules. Yes, I realize this. But most people using Perl manually install modules. That was the point of what I was saying. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [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 iQCVAwUBNhz7NY4wrq++1Ls5AQEGkwP/fL8Qmkw8difM4+UxPDZFLyuKggeUsuvW 1zj+Lffqbn7V2pRehIAgl62QLKbyOvJt0kVe/aOfoymnlI0GQzhqrjRS66sm3Ajo mS644As0/MBqueUzHuEBDrVnhcaAowuGoWEJ4IAWeuF8pwLAHyetr7pKYvC3Twrw 2LmKZ4HTygM= =Y8PI -END PGP SIGNATURE-
Re: Perl policy for managing modules ?
-BEGIN PGP SIGNED MESSAGE- Raphael Hertzog, in an immanent manifestation of deity, wrote: What about also adding /usr/lib/perl5(/$arch)? at the end of @INC ? Is it possible ? In that way, recent packages that are installed in /usr/lib/perl5/debian are used first and only if no package is found in the standard path then perl will search for modules in /usr/lib/perl5. Yes, this should be possible. I haven't actually checked but it shouldn't be a problem. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [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 iQCVAwUBNhz79I4wrq++1Ls5AQHJFwP/Z4lf/cj28nFyY5kseLjDtLJman/aZEHN q46AHFLMpuU3ce4mw9q+9nNZKDbwV6jLfXSftkZyiBY7brb1YW8+7vyRE5/u/cGu mSB+Q3UhbnnyLa/9dYJk9HY3U4+i8EUgLxKxln7Om8TKWvLwBaK3NSjjruQx4Vdy 3Bqwm1rhrPQ= =zHQR -END PGP SIGNATURE-
Perl policy for managing modules ?
Hello, I thought about the problem with directory used for installing perl modules. Actually if we do nothing, we would have to recompile all perl package for each perl5.00x release. That's because perl uses now /usr/lib/perl5/$version (and perl5/$arch/$version) as path to search for modules. And actually I count 80 packages installing perl modules so you see why another solution has to be found. I propose to make package install the modules in /usr/lib/perl5/debian and /usr/lib/perl5/debian/$arch. And the /usr/lib/perl5/$version would be a link to debian, and /usr/lib/perl5/$arch/$version a link to ../debian/$arch. So the current perl will always find the modules installed. And we'll have no problem for the transition to perl5.006 ... How to manage this in the source package for a CPAN module ? Here's what I would have to do for my own package (I tested it) : - use this line for creating the Makefile : perl Makefile.PL INSTALLDIRS=perl LIB=`pwd`/debian/tmp/usr/lib/perl5/debian - and use make pure_install for installing files What do you think about it ? Ok, it's a bit late for updating about 80 packages but I'm sorry, I didn't know this new perl feature. In summary, what we would have to do is : - modify all package with perl modules for installing them into /usr/lib/perl5/debian - make them depend on perl =5.005 (since the directory tree has changed) Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
