Bug 176658 - "pear makerpm" generates flawed RPMs (%post/%postun scripts)
Summary: "pear makerpm" generates flawed RPMs (%post/%postun scripts)
Keywords:
Status: CLOSED DUPLICATE of bug 185321
Alias: None
Product: Fedora
Classification: Fedora
Component: php-pear
Version: rawhide
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL:
Whiteboard:
Depends On: 176725
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-28 19:42 UTC by Greg Swallow
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-03-14 14:52:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Greg Swallow 2005-12-28 19:42:08 UTC
+++ This bug was initially created as a clone of Bug #173270 +++

> Fourth, the %post script should probably include a "--force" flag, otherwise ?
> pear will refuse to register a module on an upgrade.  (I haven't tested this 
> extensively.)

There were many issues fixed in the other bug report.  Just wanted to add my 2 
cents to this particular comment.  I used a combination of --force and --soft...

-s, --soft
      soft install, fail silently, or upgrade if already installed

...in the %post script (rather than the other code suggested to detect if it 
was an install or an upgrade - (but maybe this would work in addition to that 
code as well), and also added --ignore-errors in the %postun script, and it 
seems to handle upgrades *from a manual (pear install xxx) install of an older 
module* and will also cleanly uninstall the rpm even if the module was removed 
with 'pear uninstall xxx' rather than removing the rpm.

Comment 1 Tim Jackson 2005-12-31 11:13:45 UTC
Nice. That's a really neat idea. Just to clarify, have you used this:

%post
pear install --nodeps --soft --force --register-only /var/lib/pear/[Package].xml

%postun
if [ "$1" -eq "0" ]; then
    pear uninstall --nodeps --ignore-errors -r [Package]
fi

I just tried that myself with a variety of scenarios (pre-existing non-RPM
packages etc.) and it handled all situations gracefully. I like it. It's simpler
and it handles more cases. I think you should file a bug upstream (in the PEAR
bug system, bearing in mind my recent bugs 6373 and 6375 over there) and
meantime I will modify some of my roll-up fixes over in bug #176725. I'm going
to mark this bug as depending on bug #176725 in the hope that 176725 is the
"grand fix" of all "pear makerpm" issues.

Comment 2 Tim Jackson 2005-12-31 11:23:45 UTC
I've used this method on my request for a php-pear-DB package for Fedora Extras
(or maybe Fedora Core). Check it out over in bug #176733; any feedback
appreciated. Thanks for the hint Greg.

Comment 3 Tim Jackson 2005-12-31 12:04:28 UTC
I've submitted a bug and patch for this upstream:
http://pear.php.net/bugs/bug.php?id=6377


Comment 4 Greg Swallow 2006-01-01 22:44:29 UTC
Thanks Tim, that was exactly what I had.  

Comment 5 Joe Orton 2006-02-28 17:24:09 UTC
I think this is going to be a WONTFIX, or is this done upstream for PEAR-1.4.7?
 With Tim's new PEAR_Command_Packaging it's going to be possible to create
proper Fedora-standard RPMs can be produced which use all the correct paths etc.

Comment 6 Tim Jackson 2006-02-28 17:39:10 UTC
PEAR 1.4.7 has a frozen (old) version of the "makerpm" command, which will
remain for the forseeable future. However, the fork of this code which is now in
PEAR_Command_Packaging fixes this bug. Additionally, PEAR 1.4.7 has code to
auto-detect the presence of PEAR_Command_Packaging and transparently (well, with
a notice) switches to use the newer "make-rpm-spec" code if available.

So yes Joe I would mark this WONTFIX, and/or assign it to the
"php-pear-PEAR-Command-Packaging" component of the Fedora Extras product when I
get round to making it (which itself is dependent on bug #183359).

Comment 7 Joe Orton 2006-03-14 14:52:38 UTC

*** This bug has been marked as a duplicate of 185321 ***


Note You need to log in before you can comment on or make changes to this bug.