Re: important perl5.005 issues (was Re: perl version depends)
Le Fri, Oct 09, 1998 at 08:29:27AM -0400, Michael Alan Dorman écrivait: I think you should read the docs or follow the last couple of years of the perl5 development mailing list, as I have, before you suggest you know better than I. From doc/perldelta.pod: I apologise, I did not want to suggest anything like that. You know, I'm french and my english is really not perfect so I may have expressed things I didn't want. And in fact, I've read the INSTALL file a couple of times but too fast as I can see it. :-( So, IMNSHO, the smarter thing to do would be to not add /usr/lib/perl5 to @INC. Ok I agree. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: perl version depends
On Thu, 8 Oct 1998, Richard Braakman wrote: darkThat only is a large source of packaging bugs. In fact, the (IMO) darkmost annoying upgrade problem in hamm was a pathname problem: two darkpackages had moved to a different directory at the last minute, and darkthe auto upgrade script hadn't been modified to match. Also some complicated packages have perl paths hardwired in relatively obscure places (eg pdl) , and these may not show up immediatley. I agree that there is a good possibility that releasing slink with half a perl upgrade could be a disaster. If we set a policy on the paths within a day or two and then have, say three weeks, and can count on people working hard, and allowing NMU's, we can probably get the critical packages fixed (I don't know what they are). But doing it all in 7 days is not a good idea. Re: installing in /usr/lib/perl5/debian . I have an uneasy feeling about it, but no concrete objections. My guess is that Darrin has a better idea about it than me. It may be ok, I'll follow it if its set. Just to summarize, I think we have to either go back to 5.004 , or push the freeze back a couple of weeks. John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: perl version depends
On Thu, 8 Oct 1998, Michael Stone wrote: mstoneWhat I'm trying to say is why doesn't perl look in /usr/lib/perl5 mstoneanymore? Was this just a gratuitous change, or was there a reason for mstonebreaking things? I can understand the change if there are modules that mstonework in 5.004 but not 5.005, at least from the upstream perspective, but mstonedon't we already have a mechanism for handling conflicts that makes this mstoneredundant? What does /usr/lib/perl5/5.005 buy us? This is decided by the perl authors, not debian. Darrin can change things and install whereever he likes and change the include path, but we have to make sure it doesn't break things. So to the extent possible, we stay with the official perl installation. However, at least part of their rationale for the new scheme is to allow multiple versions of perl, a feature that debian is not interested in. Why they (perl guys) did not leave /usr/lib/perl5 in the search path is not clear to me. Perhaps because they assume that othe modules will install in site_perl or local. But systems with package managers, like ours don't use these dirs. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, 8 Oct 1998, Santiago Vila wrote: 2) Are we really going to freeze slink in 7 days? I dont think we should freeze until we have a broken libc in slink... -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: Freeze in 7 days??? (was Re: perl version depends)
On Fri, 9 Oct 1998, Gergely Madarasz wrote: On Thu, 8 Oct 1998, Santiago Vila wrote: 2) Are we really going to freeze slink in 7 days? I dont think we should freeze until we have a broken libc in slink... ^ Hmpf... I meant while :) -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: perl version depends
John Lapeyre [EMAIL PROTECTED] writes: However, at least part of their rationale for the new scheme is to allow multiple versions of perl, a feature that debian is not interested in. Threaded perl and non-threaded perl are binary-incompatible at the extension level, meaning most compiled extensions must be distinguishable. Furthermore, there was a lot of concern that most perl-only extensions are not yet thread-safe. Therefore, I believe, the decision was made to have all extensions, etc, reside in a arch-directory that would distinguish between thread and non-thread. So, yes, I think Debian does have to honor this, and to make our perl gratuitously different (which is to say, having it look in /usr/lib/perl5) would be inviting calamity some time down the road. I say this in full knowledge that I'm going to have to recompile a heap of perl modules next week. And I'm glad Darren didn't make a thrperl yet, so we don't have to deal with that issue immediately. Mike.
Re: perl version depends
Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait: Threaded perl and non-threaded perl are binary-incompatible at the extension level, meaning most compiled extensions must be distinguishable. I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible. But in order to support threads, they had to break the binary-compatibility beetween perl5.004 and perl5.005. That's it. So, yes, I think Debian does have to honor this, and to make our perl gratuitously different (which is to say, having it look in /usr/lib/perl5) would be inviting calamity some time down the road. Which in fact doesn't mean we cannot add /usr/lib/perl5 at the end of @INC because architecture-dependant packages will be found before. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
important perl5.005 issues (was Re: perl version depends)
Raphael Hertzog [EMAIL PROTECTED] writes: Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait: Threaded perl and non-threaded perl are binary-incompatible at the extension level, meaning most compiled extensions must be distinguishable. I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible. But in order to support threads, they had to break the binary-compatibility beetween perl5.004 and perl5.005. That's it. I think you should read the docs or follow the last couple of years of the perl5 development mailing list, as I have, before you suggest you know better than I. From doc/perldelta.pod: -8- =head2 Binary Compatibility This version is NOT binary compatible with older versions. All extensions will need to be recompiled. Further binaries built with threads enabled are incompatible with binaries built without. This should largely be transparent to the user, as all binary incompatible configurations have their own unique architecture name, and extension binaries get installed at unique locations. This allows coexistence of several configurations in the same directory hierarchy. See FINSTALL. -8- So, yes, I think Debian does have to honor this, and to make our perl gratuitously different (which is to say, having it look in /usr/lib/perl5) would be inviting calamity some time down the road. Which in fact doesn't mean we cannot add /usr/lib/perl5 at the end of @INC because architecture-dependant packages will be found before. Possibly. But, also from doc/perldelta.pod: -8- =head2 Perl Source Compatibility When none of the experimental features are enabled, there should be very few user-visible Perl source compatibility issues. If threads are enabled, then some caveats apply. C@_ and C$_ become lexical variables. The effect of this should be largely transparent to the user, but there are some boundary conditions under which user will need to be aware of the issues. For example, Clocal(@_) results in a Can't localize lexical variable @_ ... message. This may be enabled in a future version. Some new keywords have been introduced. These are generally expected to have very little impact on compatibility. See LNew CINIT keyword, LNew Clock keyword, and LNew Cqr// operator. Certain barewords are now reserved. Use of these will provoke a warning if you have asked for them with the C-w switch. See LCour is now a reserved word. -8- So, there is no guarantee that existing perl modules may not trigger new warnings or other issues when run under the new perl. So, IMNSHO, the smarter thing to do would be to not add /usr/lib/perl5 to @INC. Mike.
Re: perl version depends
Darren Stalder wrote: Is it possible for dpkg to have a depends line similar to: Depends: perl (=5.005) and have that include 5.005-\d+? Or will I need to put a = means equal. I guess it's logical that 5.005 != 5.005-1 Thus I believe it would need to use (= 5.005-0) Provides: perl5.005 in so that packages can depend on that? (Note that I did say that this would break *all* debian installed packages in the change release.) (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
On Thu, 8 Oct 1998, Martin Schulze wrote: joey(I thought that debian-devel had reached a consensous that it's not joeya good idea to change the perl version less than 14 days before joeythe code freeze.) Well perl 5.005 is now installed in slink, and when it is installed, alot of stuff breaks (anything for which perl has to include non-standard modules (there are some heavily used non-standard modules (web stuff, perl-tk perl-gtk, ... ). It was supposed to just be a scramble to recompile several things. But now its worse than that-- many more modules need to be repackaged. The worst thing is that we are facing a policy decision on how to handle the change in installation directories. It must be decided before people can begin to fix the 80 odd broken packages. And policy issues tend to get resolved slowly. Raphael suggested modules installing to /usr/lib/perl5/debian and then having the perl package include a symlink to the current version number. Raphael offered to do some NMU's if people asked. I could help too, once the policy is set. We could also force a rebuild (developers) and upgrade (users) every time x changes in 5.00x . Another option is to put the old perl back into slink until the issue can be resolved. Yet another is to configure perl to install stuff according to the old format (the perl configuration scripts can handle this easily ), since we will not have multiple version of perl in the distribution at one time, and this is what the new system is meant to handle. I wrote to perl5-porters asking for some possible tips, but have not heard back yet. I think we need to make a decision rather quickly. If there are some debian developers who know something about the perl development strategy, it would be good to hear from them. I don't know if the perl people really expect everyone to redo the 'perl Makefile.PL ... ' process for every perl package evertime perl is upgraded, but it certainly looks that way. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: perl version depends
Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait: Thus I believe it would need to use (= 5.005-0) (= 5.005) should work too, no ? (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I don't know what debian-devel reached, but in fact it seems to me that just a few people are interested by perl. :-) Some asked to wait, other wanted to switch right now in order to avoid making perl conflict with 35 packages with precise version. In fact perl5.005 uses also new directories for installing modules and that's the current problem. I proposed a little perl policy for managing it. John Lapeyre has made a good summary of solutions available. In fact Perl5.005 is in unstable and some packages (like eperl) have already been updated and uploaded for using perl5.005. If we are able to decide if this perl policy is ok, then we can start to work and it can be done quickly since the only thing to do is to add a litlle LIB=.../perl5/debian in source package and rebuild it. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: perl version depends
RH == Raphael Hertzog [EMAIL PROTECTED] writes: RH I don't know what debian-devel reached, but in fact it seems to me RH that just a few people are interested by perl. :-) If you want other voices, then count me to the 5.004 for Debian 2.1 party. I agree to Joey's arguments. Ciao, Martin
Re: perl version depends
Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait: Thus I believe it would need to use (= 5.005-0) (= 5.005) should work too, no ? Check out what dpkg thinks about it: finlandia!joey(tty5):/tmp dpkg --compare-versions 5.005 lt 5.005-1; echo $? 0 So, yes, it's also ok. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I don't know what debian-devel reached, but in fact it seems to me that just a few people are interested by perl. :-) Yes, but more people are interested in a broken perl subsystem. John Lapeyre has made a good summary of solutions available. In fact Perl5.005 is in unstable and some packages (like eperl) have already been updated and uploaded for using perl5.005. Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Darren/Torin/Who Ever... wrote: Thus I believe it would need to use (= 5.005-0) But it would also have to use ( 5.006-0). I don't think this is a problem. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I didn't realize this. I saw the comment from Manoj but I also saw several others that said they wanted to see it. We can back out the release if need be. This should be done soon though. I'll still upload a new version tonight. Since the freeze is in 7 days and I don't believe that we can fix all incompatibilities wrt the new version of perl as well as re-compiling all perl packages *after* the main perl package has stabilized, I would like to go back to the old version of perl. My proposal with this version of perl was 7 more days ago. Read: we lost 7 days of integrating perl. Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Re: perl version depends
Quoting Martin Schulze ([EMAIL PROTECTED]): Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? Mike Stone
Re: perl version depends
Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. That only is a large source of packaging bugs. In fact, the (IMO) most annoying upgrade problem in hamm was a pathname problem: two packages had moved to a different directory at the last minute, and the auto upgrade script hadn't been modified to match. I think we should fall back on perl 5.004, and only move to 5.005 when there's a real plan for upgrading cleanly. Many core utilities rely on perl, as do many maintainerscripts. This problem will *not* go away when the perl packages have been rebuilt -- the upgrade process itself will break. People will be upgrading from hamm to slink when we release it, and they will run into problems like update-inetd breaking halfway through a mass upgrade. Richard Braakman
Re: perl version depends
Michael Stone wrote: Quoting Martin Schulze ([EMAIL PROTECTED]): Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because That's the main cause of this thread... it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? I can't but s/o said that PERL5LIB=/usr/lib/perl5 would help. I haven't tried. I have copied the missing modules into /usr/lib/perl5/5.005 since I had to put the machine back online *quick*. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Richard Braakman wrote: Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. That only is a large source of packaging bugs. In fact, the (IMO) most annoying upgrade problem in hamm was a pathname problem: two packages had moved to a different directory at the last minute, and the auto upgrade script hadn't been modified to match. Speaking of the upgrade script, is there *any* reason why /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh since Sep 5th? I think we should fall back on perl 5.004, and only move to 5.005 when there's a real plan for upgrading cleanly. Many core utilities rely When slink is released it's time to break sid. No problem with this. That's the usual way to switch to newer versions of programs. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Previously Martin Schulze wrote: Speaking of the upgrade script, is there *any* reason why /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh since Sep 5th? Possibly the same reason nothing has moved from proposed-updates to stable for a long time now I guess... When slink is released it's time to break sid. No problem with this. That's the usual way to switch to newer versions of programs. unstable rather then sid.. 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/ pgpp8X3SUN0Dv.pgp Description: PGP signature
Re: perl version depends
Le Thu, Oct 08, 1998 at 02:42:59PM +0200, Richard Braakman écrivait: itself will break. People will be upgrading from hamm to slink when we release it, and they will run into problems like update-inetd breaking halfway through a mass upgrade. This would not be the case when packages will be updated. If you take slink at the present state, this sort of things will happen. But when package will be updated (including netbase for installing DebianNet.pm into /usr/lib/perl5/debian) those problem should not remain. Well I don't know how apt would do a dist-upgrade but I think, it will start with installing base/* packages. So update-inetd should work. If you think that the problem can arise before perl5.005 is installed but after netbase then the netbase package should depend or pre-depend on perl-base_5.005. And in fact such problem are only possible with DebianNet.pm, Debian::DpkgFtp or libnet modules. They are in base and other package may depend on it. We have to pay attention how they are installed. In order: 1 perl-base (here no package using DebianNet.pm/libnet/dpkg-ftp should be installed) 2 netbase 3 libnet 4 dpkg-ftp So libnet must (pre-)depend on perl-base5.005 and netbase too. Cheers, -- Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Freeze in 7 days??? (was Re: perl version depends)
Hi. 1) Don't we have to recompile all our ncurses-based apps against 4.2? 2) Are we really going to freeze slink in 7 days? I see that 1) and 2) don't mix very well. -- 76975153d9e889b854dd4ae6c231f5e9 (a truly random sig)
Re: perl version depends
On Thu, 8 Oct 1998, Martin Schulze wrote: When slink is released it's time to break sid. I guess you mean here it's time to break [codename for 2.2 (or 3.0)]. (By definition, sid will never be released). -- ad283d11c8d64562db7796279c3f4be8 (a truly random sig)
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, Oct 08, 1998 at 05:53:19PM +0200, Santiago Vila wrote: 1) Don't we have to recompile all our ncurses-based apps against 4.2? If we want all the ncurses-based apps to use the same version of ncurses, yes. I'm not sure if we have to, though if I were the release manager, I wouldn't release 2.1 before all ncurses-based apps used the same version. 2) Are we really going to freeze slink in 7 days? Yes. I see that 1) and 2) don't mix very well. That depends on what type of changes the release manager will accept into frozen. Brian, could you please state what your plans in this regard are? Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, 8 Oct 1998, Brian White wrote: The general guideline for frozen is: no new code A recompile with a new package is fine. Fixes to make something work with a change in another package is also fine. Does this mean also no new documentation? For slink, I plan to provide the texi2html-converted HTML for all my GNU packages, which means a new package foo-doc for every GNU foo package. Do I absolutely have to do this before the freeze? Will all my foo-doc packages be rejected because no new packages? -- 35068fe90da2260a88a96e33ee9316af (a truly random sig)
Re: Freeze in 7 days??? (was Re: perl version depends)
Does this mean also no new documentation? No. For slink, I plan to provide the texi2html-converted HTML for all my GNU packages, which means a new package foo-doc for every GNU foo package. Do I absolutely have to do this before the freeze? Will all my foo-doc packages be rejected because no new packages? There should be no problem with that. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.04. For this and more, visit http://www.verisim.com/
Re: Freeze in 7 days??? (was Re: perl version depends)
On Thu, Oct 08, 1998 at 05:53:39PM +0200, J.H.M.Dassen wrote: 2) Are we really going to freeze slink in 7 days? Yes. Oops, I better hurry with my pending iceconf upload. :-) Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED]| Use Debian Unternehmensberatung AG | [EMAIL PROTECTED]| GNU/Linux!
Re: perl version depends
Quoting Martin Schulze ([EMAIL PROTECTED]): Michael Stone wrote: Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because That's the main cause of this thread... it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? I can't but s/o said that PERL5LIB=/usr/lib/perl5 would help. I haven't tried. I have copied the missing modules into /usr/lib/perl5/5.005 since I had to put the machine back online *quick*. What I'm trying to say is why doesn't perl look in /usr/lib/perl5 anymore? Was this just a gratuitous change, or was there a reason for breaking things? I can understand the change if there are modules that work in 5.004 but not 5.005, at least from the upstream perspective, but don't we already have a mechanism for handling conflicts that makes this redundant? What does /usr/lib/perl5/5.005 buy us? Mike Stone
