Overriding core Perl modules
by Kenneth Porter
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.
18 years, 12 months
CGI vs mod_perl vs perl
by Chip Turner
(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
18 years, 12 months
Michael Peters review
by Warren Togami
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
19 years
FC4: modperl, CGI, and perl (problem)
by Jose Pedro Oliveira
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 *
19 years
Needed: Mission Statement
by Warren Togami
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
19 years
Creating RPMs for perl Distributions
by Jeff Fearn
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
19 years
perl 5.8.7 and FC4?
by Warren Togami
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
19 years
