perl-devel April 2005

perl-devel@lists.fedoraproject.org

9 participants
9 discussions

Overriding core Perl modules
by Kenneth Porter 04 May '05

04 May '05

This has already been touched on in a couple of other threads, more as a matter of figuring out which modules should be removed from core and made separate packages. A different approach is to use the site mechanism and library path or some extension of it to allow replacement modules to coexist with those in core. Using cpanflute2 one can use "--installdirs=site" to create a package that installs to the site directories instead of the vendor directories. This is almost sufficient to do the job, but there's no "site" directory for man pages, so one will get install-time conflicts for those. <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837> My own involvement is in installing MIMEDefang (http://mimedefang.org/) which requires a raft of Perl modules, some of which are updates to those in core. Most were easy enough to repackage with cpanflute2, but a couple required a bit of intervention to deal with unusual tarball names and conflicts with Perl core packaging.

3 11

FC3 perl update coming
by Warren Togami 02 May '05

02 May '05

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156128 FC3 perl update coming soon. This is your last chance to add obviously correct fixes to FC3 (and FC4) perl before we push the FC3 update for security reasons. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148847 This at least gives us an opportunity to push the FCGI fix that Rob has been crying about. I suspect that the FC4 perl package would be fine to push as the FC3 update if we remove the CGI version upgrade. We of course need to do some verification and testing here before doing it. Warren Togami wtogami(a)redhat.com

3 7

CGI vs mod_perl vs perl
by Chip Turner 02 May '05

02 May '05

(sorry for starting a new thread; just joined the list) Ahh, the age old conflict of the modules inside of perl vs the modules external to it. Ahh, the pain. Damned if you do, damned if you don't. ... time for a story ... Once upon a time, the happy new Perl maintainer looked around and saw several parts of perl that (he thought) would need updating regularly. "I know what to do!" he said aloud, and quickly split the perl package up into a main perl package and various subpackages such as perl-CGI. "Now when a new perl-CGI comes along, we just release a new RPM made from the CGI upstream distribution, replacing the one that originally was part of perl!" Woe be unto him, though, that releases an update to a package that comes from a different source rpm. The sky will crack and the earth will boil! Users will be confused, and tools will be flustered. Especially if newer versions of that original package are released, then obsoleting the first update that was from a different source rpm! And so, only after splitting out the packages did the happy new Perl maintainer realize the error of his ways. Unable to make ammends for past sins, he tucked his tail between his legs, turned the nasty split perl package back into a single package, and went to pay his penance (mucking the stalls for the king). ... the end ... So my original idea of solving this problem once was to split out perl-CGI and then release updates to it. Bad idea. Wouldn't have worked. So subsequently what I did with things like perl-Time-HiRes was completely destroy them from the perl package so that they -had- to be external packages. You can see examples of such expurgation in the current perl.spec file: find $RPM_BUILD_ROOT -name '*HiRes*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*Filter*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv Begone! Begone, foul packages. So, this is an option for perl-CGI going forward, if frequent updates are anticipated. If not, though, I would recommend just patching it inside of the perl specfile. I am pretty sure I've done that in the past (even with CGI.pm, iirc) with success. Including the upstream CGI tarball, though, in the RPM as another Source would probably be more trouble than it is worth in terms of getting it to build right and then later updating the spec file to perl 5.8.7 which would no longer need the CGI.pm (in one case you just remove a patch file and a %patch statement; in the other, you excise chunks of the build, etc). HTH, Chip -- Chip Turner cturner(a)pattern.net

2 2

Well here we are
by Rob Kearey 28 Apr '05

28 Apr '05

OK, I'll start with a big, ugly one. CPAN+ can build debian packages with CPANPLUS::Dist. Would it be worthwhile creating an RPM target? Damn you, RT. -- Rob Kearey Website: http://apac.redhat.com Red Hat Asia-Pacific Legal: http://apac.redhat.com/disclaimer +61 7 3514 8102 Stuff: http://people.redhat.com/rkearey

8 14

Michael Peters review
by Warren Togami 24 Apr '05

24 Apr '05

http://mpeters.us/fc_extras/ Michael Peters is requesting cvsextras access. Among his packages are some perl packages. Are these good? (This is not the only criteria I am judging for his membership, I am reviewing his other activites in other mailing lists to judge cluefulness.) Warren Togami wtogami(a)redhat.com

1 0

FC4: modperl, CGI, and perl (problem)
by Jose Pedro Oliveira 24 Apr '05

24 Apr '05

Warren, We have another major problem with mod_perl 2.0.0 RC5 as it also requires CGI.pm version 3.08 which has just hit CPAN today (a couple of hours ago). CGI.pm is one of the perl modules affected by the module rename (Apache:: -> Apache2::) done in mod_perl RC5. Problem: How to package CGI 3.08? CGI.pm is a dual life perl module: shipped with perl and also shipped as an independent module . Possible solutions: 1) patching perl-5.8.6 2) remove CGI from the core perl package and and go back to perl-CGI as it was done in Red Hat 7.3, 8, and 9 3) wait for perl-5.8.7 and hope that it includes CGI 3.08. Option 3 is rather optimistic. Even if perl-5.8.7 is released next week, it will probably be to late to include it in FC4. Option 1 or option 2? Right now I would go for option 2. It will be easier to release updates if something is still broken. Comments? [Warren: is there any change of updating perl after test3 if it doesn't break anything?] Regards, jpo PS - Joe Orton knows about this problem. One of the mails in the mod_perl mailing list was his. References: [1] mod_perl 2.0 renaming http://perl.apache.org/docs/2.0/rename.html [2] Lincoln D. Stein > CGI.pm http://search.cpan.org/dist/CGI.pm/ -- José Pedro Oliveira * mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *

3 7

Needed: Mission Statement
by Warren Togami 24 Apr '05

24 Apr '05

We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set. Some ideas for the mission statement: * Agreement and documentation of perl packaging standards * Cleanup and maintenance of Core and Extras perl packages * Discussion of perl package development issues * Progressive packaging of CPAN toward Extras Anything we're missing? This week we need to figure out ways of better keeping the team informed about new bugs, triage and setting priorities, and tracking open issues. I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs(a)redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher. I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume. Warren Togami wtogami(a)redhat.com

2 4

Creating RPMs for perl Distributions
by Jeff Fearn 20 Apr '05

20 Apr '05

Hi all, I'm doing a little hacking for RobK trying to get cpan2rpm to recursively build rpms for perl modules. I have it working for perl Modules but am stuck trying to work out how to handle Distributions, such as libapreq. I can get them to d/l and supply dependencies etc, I just haven't figured out how to convert the tar to an rpm. Any pointers are most welcome :) Jeff

1 0

perl 5.8.7 and FC4?
by Warren Togami 20 Apr '05

20 Apr '05

How soon is perl-5.8.7 coming? Freeze for test3 is coming April 27th, so if we want perl-5.8.7 in we need upgrade it, test and fix all dependencies and prove that it doesn't cause widespread problems by the 26th. It is highly unlikely we will be able to upgrade to perl-5.8.7 after test3 unless the change is really only minor. How large of a difference is it between 5.8.6 and 5.8.7? It maintains binary compat right? Any other potential issues? Warren Togami wtogami(a)redhat.com

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel April 2005