[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: RFE: an test harness for rpm
From:       Jeff Johnson <n3npq () mac ! com>
Date:       2008-04-18 17:39:52
Message-ID: 2ADEDDB4-55CD-4B1A-8649-725B08677B09 () mac ! com
[Download RAW message or body]


On Apr 18, 2008, at 11:35 AM, devzero2000 wrote:

> Thanks for the reply.
>
> Yes, I know of test harness in the source RPM. But I doesn't think  
> it is so straight fowrward to expand
> it, not for the implementation but for the test case to produce. Un  
> package manager so rich of function
>  as RPM it isn't so simple to test, i think you agreed with this.
>

Depends on what the goal is. The test-harness within rpm is extensible.

However, the test-harness is more focussed on a system rather than  
unit test. Ehich
is exactly what was needed to capture --rollback elements, or  
guaranteeing no regressions
from previous behavior.

There are several pending (well the problems have been known for  
years) efforts that
I have not attempted because everyone wants "No change." And so rpm  
limps along with
broken "same old" instead of fixing.

Perhaps the most important is commiting to a means to distinguish  
upgrades
from erasures in multilib %preun/%postun scripts. Details originally at
     https://bugzilla.redhat.com/show_bug.cgi?id=127359
now tracked by Fedorable at
     https://bugzilla.redhat.com/show_bug.cgi?id=340391

I managed to sneak the next piece of the solution, macro
expanding scriptlet bodies, into rpm-5.0. The remaining
piece to "fix" the issue is to write an efficient (i.e. headers do
not have to be loaded) rpmdbCountPackages that generates
a per-color (or per-arch if you wish) count for use by expanding
in %preun/%postun bodies. The rpmdb index that is needed
to compute the per-arch count I managed to sneak into rpm-4.4.8
or so: /var/lib/rpm/Packagecolor.

I also have most of the implementation for an efficient join between
the Name and Packagecolor indices completed privately for like 1.5  
years now.

What stops me (and what a unit test harness would most definitely
help with) is that _EVERYONE_ is going to suddenly pretend not
to understand how rpm functions if/when I deploy a change to how
arguments are handled by package scriptlets. Lord nows that $1 and $2
(and the even worse $3 and $4 change in a patch in bugzilla) is
a feeble and deficient and obscure and often misused "feature" of rpm.

All that is needed is means to distinguish "update" from "erasing", $1
and $2 and counting packages is very much a hacky design flaw dating
back to when triggers were implemented in rpm during December 1997.

There are several other implementations that are needed, including
phasing out scriptlets from rpm and using lua instead (Shhh! you dinna
hear that from me, sigh) that a test harness would assist. (Hint:  
there are
too many side effects, and too much overhead with ordering and  
dependencies
and ..., that is necessary solely to permit package monkeys the  
illusion that
their scripting is important for package installation). See the  
thread on rpm-maint
regarding /sbin/ldconfig for one recent example of the confusions  
that having
external scripts introduce to package management. Internal lua from  
parameterized
templates would be so so much more reliable).

I'd also like to attempt coverage metrics in rpm code, and that can  
only be
done with some test harness to drive the coverage metrics.

73 de Jeff
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org
[prev in list] [next in list] [prev in thread] [next in thread]