Bug 165907

A couple of days ago I talked to Warren and I proposed him
the following steps (patches) to update the rawhide perl
to 5.8.7.


First patch against perl 5.8.6 specfile
---------------------------------------

   goals:
   * reformat specfile
   * correct a couple of things
   * drop the MANIFEST.all file (perl package)
   * drop the MANIFEST.suidperl file (perl-suidperl package)

Second patch against perl 5.8.6 specfile
----------------------------------------

   goals:
   * handle the removal of core modules vs external packages
     (perl-Filter, perl-Filter-Simple, and perl-Time-HiRes)

Third patch against perl 5.8.6 specfile
---------------------------------------

   goals:
   * update it to 5.8.7
   * remove the CGI.pm patches

   status:
   * still incomplete as four patches fail to apply


Other comments/suggestions/patches are welcome.

jpo

Current status: 
The first patch has already been applied (see perl-5.8.6-16.src.rpm in rawhide)


First patch summary: perl-5.8.6-15 => perl-5.8.6-16
===================================================
 * Specfile reformatted
     - in particular grouped all the patches together
 * Full URL of the perl 5.8.6 tarball
 * %build section
     - moved the mkdir commands that appeared before the
       Configure line into the %install section
     - Configure command argument changes
         -Dversion
         -Dinstallprefix
          (make install DESTDIR=$RPM_... in %install)
 * %install section
     - make install DESTDIR=$RPM_BUILD_ROOT
     - no longer creates MANIFEST.all
     - dropped compression of the man pages
 * %files section
     - no longer uses MANIFEST.all for the perl package
     - no longer uses MANIFEST.suidperl for the perl-suidperl subpackage
 * Source files no longer needed
    - Source1: clean-manifest.pl
    - Source9: MANIFEST.suidperl
    - Source10: system-owned-directories

Other notes:
 * didn't move "make test" into the %check section
   Reason: the perl building process prints a message if the "make install"
   step is started without having executed "make test" before


Wish/pending list:
* mark libnet.cfg as a configuration file?
  maybe move it to /etc and create a symbolic link to it?
* reformat/clean the %install section
  I don't have access to a x86_64 (or 64 bit) machine to test the
  multilib stuff
* mark pod files as docs
  should be done at the RPM level - other perl packages (and maybe
  Ruby) would also profit from it

Created attachment 117713 [details]
Second patch - core modules

Created attachment 117714 [details]
Source file needed by the second step

The second patch no longer deletes the following core modules:

  * Filter::Util::Call        (external package perl-Filter)
  * Filter::Simple            (external package perl-Filter-Simple)
  * Time::HiRes               (external package perl-Time-HiRes)

and obsoletes the following FC-4 core packages:

  * perl-Filter
  * perl-Filter-Simple
  * perl-Time-HiRes


Notes:
* the find command with the globbing expression *Filter* also removed
  the DBM_Filter module.  I changed the above globbing to *DBM_Filter*
  in order to keep the previous behaviour.
 

The file in comment #4 is just a precaution because:

  * all perl versions 5.8 have been shipping with Filter::Simple version 0.78

    Output from   "corelist -a Filter::Simple"
    perl      Filter::Simple
    ...
    5.008      0.78
    5.008001   0.78
    ...
    5.008006   0.78
    5.008007   0.78
    ...

  * Fedora shipped Filter::Simple 0.79 as an external package 
    (FC4: perl-Filter-Simple-0.79)

  * there is no change to the module between version 0.78 and 0.79 (expect the
    the version)

    Diff from Filter-Simple-0.78 to Filter-Simple-0.79
    http://search.cpan.org/diff?from=Filter-Simple-0.78&to=Filter-Simple-0.79
    

Isn't it a good idea to wait until the third patch is complete before pushing
this to rawhide?  I want to avoid the case of the version of obsoleted
perl-subpackage modules going backwards temporarily.

*** Bug 158383 has been marked as a duplicate of this bug. ***

Re comment 2: what harm does "prints a message" do if "make install" is run 
before "make test"? 

(In reply to comment #9)
> Re comment 2: what harm does "prints a message" do if "make install" is run 
> before "make test"? 

None.

(In reply to comment #7)
> ... I want to avoid the case of the version of obsoleted
> perl-subpackage modules going backwards temporarily.

Can you be more specific? Which perl-subpackage/module would be going backwards?


Additional info about Perl and core modules versions
(source: corelist):

Perl      Filter::Simple  Filter::Util::Call  Time::HiRes
5.008005      0.78            1.0601              1.59
5.008006      0.78            1.0601              1.65
5.008007      0.78            1.0601              1.66

FC4 - Perl core modules in external packages

   perl-Filter-1.30-7.i386.rpm
      * includes Filter::Util::Call version 1.06
   perl-Filter-Simple-0.79-5.noarch.rpm
   perl-Time-HiRes-1.65-1.i386.rpm

Example of strange dependencies

   $ rpm -q --whatrequires "perl(Filter::Util::Call)"
   perl-5.8.6-15
   $ rpm -q --whatprovides "perl(Filter::Util::Call)"
   perl-Filter-1.30-7

Created attachment 117724 [details]
Third perl specfile patch - comments four perl patches

The release number is intentionally 0 (zero) as this perl specfile patch has to
temporarily disable the following perl patches:

  Patch11:	  perl-5.8.3-fullinc.patch
  Patch12:	  perl-5.8.6-incpush.patch
  # CAN-2004-0452 fix
  Patch26:	  perl-5.8.0-rmtree.patch
  # CAN-2005-0155 and CAN-2005-0156 fix
  Patch27:	  perl-5.8.5-CAN-2005-0155+0156.patch

Any volunteers to review the above patches?

Created attachment 117761 [details]
Patch12, updated for 5.8.7

this the inpush patch (patch12), updated as jpo.pt requested.

as for the other patches: 26 was fixed by change 24180 and 27 by change 23918.
(no idea about 11, i don't use it).

> Second patch - core modules
JPO, if you are at this, please add versions to all those Obsoletes packages,
something like:
Obsoletes: perl-Time-HiRes <= 1.65

This way, in a future ideal world maybe we could be able to build our own
perl-CGI, perl-CPAN, etc updated packages without having to cope with the "main"
perl package.

On Thu, 2005-08-18 at 13:16 -0400, bugzilla wrote:
> ------- Additional Comments From altblue  2005-08-18 13:16 EST -------
> > Second patch - core modules
> JPO, if you are at this, please add versions to all those Obsoletes packages,
> something like:
> Obsoletes: perl-Time-HiRes <= 1.65
>
> This way, in a future ideal world maybe we could be able to build our own
> perl-CGI, perl-CPAN, etc updated packages without having to cope with the
> "main" perl package.

Is there an "approved" way of packaging later versions of specific
modules that are bundled with the perl rpm? This is sometimes needed to
satisfy dependencies, particularly for legacy distros.

Paul.
--
Paul Howarth <paul>

Paul, let's keep it all in one place ;-)

> Is there an "approved" way of packaging later versions of specific
> modules that are bundled with the perl rpm? This is sometimes needed to
> satisfy dependencies, particularly for legacy distros.

If there is one, I haven't heard about it. All I know is there were some
discussions on this issue on the various RedHat/Fedora mailing lists, but AFAIR
there was no (positive) conclusion.

So, for what it worths, what I do now is something like: build packages for
those updated module replacing the usual %{_mandir} (/usr/share/man) with
/usr/local/share/man, replacing %{_bindir} (/usr/bin) with /usr/local/bin, and
using vendor install for the modules.
It's nasty/ugly/bad/etc ... but it's my (bad) way and "works for me".

OFC, this way I cannot either use the stock RH/FC perl package (those missing
versions in Obsoletes being an issue).

This is getting off topic in this particular Bugzilla report, but I've earlier 
suggested prefixing all of site_perl (modules, man pages, bin etc) 
to /usr/local so it could be easily used for local core/vendor Perl overrides, 
packaged or not.  As expected, some people liked the suggestion, some didn't 
-> nothing hasn't happened, at least yet... 

Patch11, Patch26, and Patch27 need verification as they clash with perl-5.8.7
and it is uncertain whether all of that has been upstreamed.  Otherwise this has
been built in rawhide and will be on the mirrors tomorrow.

For the record:
The packages - perl-Filter, perl-Filter-Simple, and perl-Time-HiRes - were
removed from rawhide.

Source:
rawhide report: 20050913 changes
https://www.redhat.com/archives/fedora-devel-list/2005-September/msg00227.html

Details:
...
Removed package perl-Time-HiRes

Removed package perl-Filter-Simple

Removed package perl-Filter
...

See also: #136494 and #167901