ts.order() returns wrong packages erasing order for 'yum remove' and 'yum groupremove'

Description of problem:
ts.order() returns wrong package removal order for yum remove/groupremove

Version-Release number of selected component (if applicable):
  rpm-4.4.2-47.el5.x86_64
  rpm-python-4.4.2-47.el5.x86_64
  yum-3.0.5-1.el5.centos.5.noarch

How reproducible:
  Every time.

Steps to Reproduce:
1. create 4 packages PA, PB, PC, PP, let PA, PB and PC depends(requires)
package PP; Let the %preun scripts of PA, PB, PC refers to files in PP.

2. run 'yum install PA PB PC PP' to install all 4 packages. this will install
all 4 packages without problems.

3. run 'yum remove PA PB PC PP' now, it will fails the operation: only PA, PP
are removed, while the removal of PB and PC failed because the %preun scripts'
failure of PB and PC. The reason is: the depended packge PP is removed before
PB and PC and so gone the file(s) refered.

Actual results:

 PA, PP removed; PB, PC failed. the remove operation returns wrong results.

Expected results:

 All PA, PB, PC and PP should be removed

Additional info:

 The ts.order() returns wrong results.

 After the ts.orders() is run at line 470 in /usr/share/yum-cli/cli.py in
debugging mode, the debugging code "for te in self.ts: print te" returns:

 'PP, PB, PC'

 Thi is good for installation/upgrade operation, but for removal operation,
the correct sequence should be:

 'PB, PC, PP'

 because removal of PP will definitely fail PB, and PC.

Observation:

 command line 'rpm -e PA PP PB PC' has reported no problems, but we need the
python based 'yum remove' and 'yum groupremove' for automatic administration.
'yum groupremove' has the same problem as 'yum remove', which as skvidal of
yum development said, due to the bug of ts.order() from rpm-python/rpm.

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

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

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

Proper erasure ordering is implemented in RHEL 6 rpm. It is not however backportable to RHEL 5 due to the API changes it requires.