Skip Menu |

This queue is for tickets about the autodie CPAN distribution.

Report information
The Basics
Id: 37901
Status: rejected
Priority: 0/
Queue: autodie

People
Owner: PJF [...] cpan.org
Requestors: EDAVIS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.99
Fixed in: (no value)



Subject: Do not require clobbering Fatal
Replacing the existing Fatal.pm causes trouble with packaged Perl distributions (RPMs and the like) because you have two packages claiming to own the same file. If the perl core is upgraded then Fatal.pm will get clobbered back again. Also from a cautious sysadmin's point of view, installing a new module is fairly safe but replacing a Perl core module is not. Is it possible to have autodie install Fatal_for_autodie.pm instead and load that? If autodie interacts badly with the old version of Fatal, then check at load time that a program does not try to load both.
G'day Ed, Sorry for the delay, I've been rather busy at OSCON the whole week. On Thu Jul 24 07:10:04 2008, EDAVIS wrote: Show quoted text
> Replacing the existing Fatal.pm causes trouble with packaged Perl > distributions (RPMs and the like) because you have two packages claiming > to own the same file. If the perl core is upgraded then Fatal.pm will > get clobbered back again. Also from a cautious sysadmin's point of > view, installing a new module is fairly safe but replacing a Perl core > module is not.
Oh boy, where do I begin here? Unfortunately, this is a common headache with all the dual-life modules out there on the CPAN. If you have CGI.pm, then it comes bundled with Perl, but at the same time there are updates released to the CPAN. Fatal (and hence autodie) is in the same boat, although the decision to dual-life the module is much more recent. The *ideal* situation for dual-life modules is they don't overwrite the ones that come with core, they just install themselves in an earlier position in @INC. That solves the double file problem nicely, but it's always been traditional in Unix distros to check the Perl core modules first. Autodie should come as a standard core module in 5.8.9 and 5.10.1. Show quoted text
> Is it possible to have autodie install Fatal_for_autodie.pm instead > and load that?
Show quoted text
> If autodie interacts badly with the old version of Fatal, then check > at load time that a program does not try to load both.
If autodie hadn't been approved for core distrubtion, then this is exactly what I would have done. Unfortunately it results in a rather sub-optimal solution. Without replacing some of Fatal's brains, autodie can't easily tell the different between a user-sub and a Fatalised built-in, and this can result in all sorts of strange interactions. Having autodie overwrite (in memory) Fatal's guts works, but requires specific loading orders for the modules, and from an end-user standpoint these don't make much sense. The current solution, while a pain for many common distros at the moment, does result much much nicer code overall, no strange actions from a distance, and less work in when 5.8.9 and 5.10.1 come out (where autodie will be standard). All the very best, Paul
Yes, it's a more general problem. I think I would still prefer a 'lite' autodie mode where it does not overwrite Fatal.pm but just adds die 'cannot load both autodie and old Fatal in the same program' if defined $Fatal::VERSION; to autodie.pm. But if it is to be included in 5.10.1 then I will just wait for that.
G'day Ed, Just a quick note to say that I've been building autodie with dh-make-perl under Debian, and everything works an absolute treat: dh-make-perl --build --cpan autodie The debian package installs itself into /usr/share/perl5/ which takes precedence over the system /usr/share/perl/5.8/ . This means everything works without conflicts in the package system, and if the autodie package is removed, then the legacy Fatal.pm just takes over. So installing autodie on Debian systems should not be a problem. I don't know how things work in the .rpm world, since all my machines are Debian based. If you find a command that builds a nice .rpm that doesn't cause conflicts (if this is possible), I'd love to hear about it. If other dual-life modules (like CGI) are able to get around these issues, then autodie should be able to as well. I do have getting autodie packaged and into mainstream distros on my TODO list, but due to a full work schedule I won't have any time to take much action on this for a few weeks. Cheerio, Paul
G'day Ed, Just a short note to say that I'm marking this ticket as resolved. On Debian and Windows based systems where autodie can be installed higher up on the @INC path than the core modules that come with Perl, then autodie will install itself in this location, so it won't clobber Fatal.pm, it will just shadow it. For other systems, there's no good solution (yet), but this isn't just an autodie specific problem, this is for any dual-life module (such as CGI). I'm afraid that autodie will never be decoupled from Fatal. They share a huge amount of code in common, and they also have a great scope for conflict if broken apart. All the very best, Paul
CC: EDAVIS [...] cpan.org
Subject: Re: [rt.cpan.org #37901] Do not require clobbering Fatal
Date: Wed, 3 Dec 2008 11:53:31 +0000 (GMT)
To: PJF via RT <bug-autodie [...] rt.cpan.org>
From: Ed Avis <ed [...] membled.com>
On Tue, 2 Dec 2008, PJF via RT wrote: Show quoted text
>Just a short note to say that I'm marking this ticket as resolved. On >Debian and Windows based systems where autodie can be installed >higher up on the @INC path than the core modules that come with Perl, >then autodie will install itself in this location, so it won't >clobber Fatal.pm, it will just shadow it. For other systems, there's >no good solution (yet), but this isn't just an autodie specific >problem, this is for any dual-life module (such as CGI).
This is very true. I'm currently waiting for perl 5.10.1 to come out to resolve this mess :-(. -- Ed Avis <ed@membled.com>