Bug 155700

Summary: An info file viewer.
Name: pinfo
Version: 0.6.8
Release: 10
Group: System Environment/Base
License: GPL
URL: http://dione.ids.pl/~pborys/software/pinfo
# Actual source is .gz'd so I put the URL here, but convert to bz2
#Source: http://dione.ids.pl/~pborys/software/pinfo/pinfo-%{version}.tar.gz
Source: pinfo-%{version}.tar.bz2
Patch0: pinfo-0.6.8-mkstemp.patch
Patch1: pinfo-0.6.8-htmlview.patch
Patch2: pinfo-0.6.8.memcorruption.patch
Patch3: pinfo-0.6.8.memleak.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-root
BuildRequires: ncurses-devel
Requires: htmlview
Requires(post,preun): /sbin/install-info

[SNIP]

%changelog
* Thu Mar  3 2005 Mike A. Harris <mharris> 0.6.8-10
- Rebuilt with gcc 4 for FC4
- Replaced Prereq: with Requires(post,preun)



Since the rpm spec file clearly lists the dependancies it requires,
this looks like a bug in rpm.

Here's how to reproduce 100%

1) Download
ftp://people.redhat.com/mharris/testing/unstable/pinfo/0.6.8-10/SRPMS/pinfo-0.6.8-10.src.rpm

2) Download the i386 "info" rpm for the OS release you're using

3) rpm -e pinfo ; rpm -e --nodeps info

4) Now try to install "info" and "pinfo" at the same time using the
   exact commandline that follows (adjusting version of 'info' if
   necessary):

rpm -ivh info-4.7-5.i386.rpm /home/mharris/rpmbuild/RPMS/pinfo-0.6.8-10.i386.rpm

Result:
[root@laser /]# rpm -ivh info-4.7-5.i386.rpm
/home/mharris/rpmbuild/RPMS/pinfo-0.6.8-10.i386.rpm
Preparing...                ########################################### [100%]
   1:pinfo                  ########################################### [ 50%]
/var/tmp/rpm-tmp.549: line 1: /sbin/install-info: No such file or directory
error: %post(pinfo-0.6.8-10) scriptlet failed, exit status 127
   2:info                   ########################################### [100%]

You must use the 0.6.8-10 pinfo rpm as this is the only one that has
the Requires(foo,bar) syntax.


If I swap the rpm package args around however:

rpm -ivh  /home/mharris/rpmbuild/RPMS/pinfo-0.6.8-10.i386.rpm info-4.7-5.i386.rpm

... then it installs without the dependancy failure.

[root@laser /]# rpm --qf '[%{REQUIRENAME} %{REQUIREFLAGS}\n]' -qp
pinfo-0.6.8-10.i386.rpm
warning: pinfo-0.6.8-10.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8
/bin/sh 1280
/bin/sh 2304
/sbin/install-info 3072
config(pinfo) 268435464
htmlview 0
libc.so.6 16384
libc.so.6(GLIBC_2.0) 16384
libc.so.6(GLIBC_2.1) 16384
libc.so.6(GLIBC_2.3) 16384
libc.so.6(GLIBC_2.3.4) 16384
libncurses.so.5 16384
rpmlib(CompressedFileNames) 16777226
rpmlib(PayloadFilesHavePrefix) 16777226

Requires(pre,postun):   foo => REQUIREFLAGS 4672

From rpmlib.h

#define _notpre(_x)             ((_x) & ~RPMSENSE_PREREQ)
#define _INSTALL_ONLY_MASK \ 
_notpre(RPMSENSE_SCRIPT_PRE|RPMSENSE_SCRIPT_POST|RPMSENSE_RPMLIB|RPMSENSE_KEYRING)

#define _ERASE_ONLY_MASK  \
    _notpre(RPMSENSE_SCRIPT_PREUN|RPMSENSE_SCRIPT_POSTUN)

#define isLegacyPreReq(_x)  (((_x) & _ALL_REQUIRES_MASK) == RPMSENSE_PREREQ)
#define isInstallPreReq(_x)     ((_x) & _INSTALL_ONLY_MASK)
#define isErasePreReq(_x)       ((_x) & _ERASE_ONLY_MASK)

From lib/depends.c

            case TR_ADDED:
                /* Skip if not %pre/%post requires or legacy prereq. */
                if (isErasePreReq(Flags)
                 || !( isInstallPreReq(Flags) || isLegacyPreReq(Flags) ) )
                    /*@innercontinue@*/ continue;
                /*@switchbreak@*/ break;

(pre,postun) gets caught by the isErasePreReq (which is true of the postun) and
shortcircuits so the relation is skipped.  

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

You might want to CC the people from the original bug.

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

rpm  4.4.1-11 in rawhide should resolve this.

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

I think we can be confident this is indeed fixed.

The remaining three scriptlet errors in Raw Hide are definitely issues in the
respective packages.  (and none in Java packages any more! yay :)

By the way, overholt told me that you need to use absolute in %post for
anaconda.  Is that really necessary, and if so why?

Oops, this is not fixed or it has resurfaced.

With rpm-4.4.1-19 and yum-2.3.2-2; I tried to nuke all java stuff from my
FC4t3+Rawhide box, and did "yum remove libgcj".

java-1.4.2-gcj-compat got removed before ant and eclipse-gcj in the transaction,
causing breakage:

  [...]
  Removing  : java-1.4.2-gcj-compat        ####################### [ 5/12]
  [...]
  Removing  : ant                          ####################### [11/12]
/home/scop/rpmbuild/tmp/rpm-tmp.15391: line 1: rebuild-gcj-db: command not found
error: %postun(ant-1.6.2-3jpp_6fc.i386) scriptlet failed, exit status 127
  Removing  : eclipse-ecj                  ####################### [12/12]
/home/scop/rpmbuild/tmp/rpm-tmp.15391: line 1: /usr/bin/rebuild-gcj-db: No such
file or directory
error: %postun(eclipse-ecj-3.1.0_fc-0.M6.20.i386) scriptlet failed, exit status 127

At least ant, eclipse* and mx4j in FC devel use the "Requires(foo,bar)" syntax
to ensure rebuild-gcj-db is available at scriptlet time.  Maybe the earlier
workaround of splitting that into two: "Requires(foo): ..." and "Requires(bar):
..." should be applied in them (and other affected packages) until it's really
fixed in rpm.

Checking header:

Requires(post,postun): java-1.4.2-gcj-compat >= 1.4.2.0-40jpp_16rh

rpm --qf '[%{REQUIRENAME} %{REQUIREFLAGS}\n]' -qp mx4j-2.1.0-1jpp_7fc.i386.rpm 
| grep comp
java-1.4.2-gcj-compat 5196

>>> x = rpm.RPMSENSE_SCRIPT_POSTUN
>>> x |= rpm.RPMSENSE_SCRIPT_POST
>>> x |= rpm.RPMSENSE_GREATER
>>> x |= rpm.RPMSENSE_EQUAL
>>> x
5196

Test erase ordering:

Install
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth,
breadth)
D:     0    0    1    0    1    0   +required-1.2-1.noarch
D: ========== successors only (1938 bytes)
D:     1    1    0    0    2    0     +requirer-2.0-1.noarch

Erase:
D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth,
breadth)
D:     0    0    0    1    1    0   -required-1.2-1.noarch
D: ========== successors only (0 bytes)
D:     1    0    0    0    1    1   -requirer-2.0-1.noarch
D: mounted filesystems:

rpm sorts that fine for me with a single dep.

Running Transaction
  Removing  : required                     ######################### [1/2]
  Removing  : requirer                     ######################### [2/2]
/var/tmp/rpm-tmp.39887: line 1: /usr/opt/required/required: No such file or
directory
error: %postun(requirer-2.0-1.noarch) scriptlet failed, exit status 1

Removed: required.noarch 0:1.2-1 requirer.noarch 0:2.0-1

Ville please raise a new bug against yum as rpm cli is working as expected

Bug 158577 noted, thanks.

Unfortunately, I'm going to have to reopen this one too once again.

The Requires(foo,bar) syntax is still broken; the "weird eclipse-ecj error" I
mentioned in bug 158577 comment 8 happens because of this, with plain "rpm -e".
 Reproducer specfile in a jiffy.

Created attachment 114839 [details]
Reproducer specfile: Requires(foo,bar) syntax is broken

Here's the reproducer.	rpmbuild it, then on FC4t3, rpm-4.4.1-21:

  # rpm -i deps-require*
  required: %pre
  required: %post
  requirer1: %pre
  requirer1: %post
  requirer2: %pre
  requirer2: %post

So far so good, but here comes trouble:

  # rpm -e deps-required deps-requirer1 deps-requirer2
  requirer2: %preun
  requirer2: %postun
  required: %preun
  required: %postun
  requirer1: %preun
  requirer1: %postun

Oops.  "required" went away before "requirer1".  Note that requirer1 and
requirer2 are exactly the same, except that requirer1 uses the
Requires(foo,bar) syntax while requirer2 uses the split-into-two Requires(foo)
and Requires(bar).  requirer2 works as expected, requirer1 not.

This is a regression, rpm-4.3.2-21 in FC3 produces the expected results:

  # rpm -e deps-required deps-requirer1 deps-requirer2
  requirer2: %preun
  requirer2: %postun
  requirer1: %preun
  requirer1: %postun
  required: %preun
  required: %postun

Ville please open a new bug, rather than adding to this one - erase ordering is
v. new and historically has never been done.

*sigh*

This bug was originally filed as #118773, which was first closed as dupe of
#118780, which describes the same problem.  Then it was bounced back as
non-dupe, and #118773 was closed as a dupe of this one.  Later, #118780 comment
6 said that the problem was identified and a tested fix existed and it was also
later set as a dupe of this.  And now this bug has been closed as fixed, all
other reports are set as dupes, the problem remains unfixed, and I'm being asked
to report it once again somewhere anew.

Sorry, I am getting really tired of chasing this same bug around Bugzilla and
having a hard time convincing myself that adding yet another bug report would
result in anything else than it being quickly set as a dupe of #118780, #118773
or this one.  Are you really sure you want me to report this again somewhere?

Please also note comment 16: erase ordering appears to work fine if one avoids
the "Requires(foo,bar): quux" syntax and uses "Requires(foo): quux" and
"Requires(bar): quux" instead.  Wouldn't it be easier just to nuke the fragile
comma separated Requires(foo,bar) syntax and be done with this?  Or am I just
being unbelievably lucky with my test cases so that it just always *appears*
that the split syntax works everywhere as expected?

Erase transaction sorting was NEVER done before.

The reason I'd want a new bug is to prevent erase sorting bugs holding up FC4 -
as install pre,post should be fine and this is a similar bug in new
functionality.  Having erase sorting split out makes it easier for me to focus
on the task in hand.

The reason  rpm -e deps-required deps-requirer1 deps-requirer2 appeared to
workwas we simply inverted the order of erasures IIRC. Try specifying alternate
orders in FC3 to confirm.  In the meantime I'm looking at this right now.

Ville I might have something to test momentarily.

Re: comment 19: confirmed, shuffling around command line arguments shows that it
doesn't work in FC3 either, so not a regression.

Erase ordering is now bug 158577.  Going to bump this one back to closed