[Rpm-maint] RPM 4.11.0 beta1 released

[Panu Matilainen]

On 12/18/2012 01:31 PM, Thierry Vignaud wrote:
> On 18 December 2012 09:53, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
>>>> not to fail in such a way.
>>>> It's not a "regression" that would affect lot of users but it may
>>>> break other package managers.
>>>> It would be better to return if no packages has been added to the
>>>> transaction.
>>
>> It's a regression alright, it affects rpm itself as well in some corner
>> cases. rpmtsRun() explicitly handles the empty transaction as a non-error
>> but the development-time safe-guard assert() triggers on rpmtsCheck() /
>> rpmtsOrder(). Will fix before 4.11 final.
>
> I take you don't like my patch :-)

Heh, I didn't say that. I just suspect there are other similar gotchas 
around, so it's probably simpler to ensure a pool always exists rather 
than try patch up all the possible cases to deal with NULL pool. Or 
something... there are surprisingly many subtleties involved.

>
>>> Eg, for the record, this is breaking perl-RPM4 too...
>>
>>
>> Out of curiosity, how/why exactly is it breaking perl-RPM4?
>
> It breaks its testsuite:
> http://rpm4.zarb.org/svn/trunk/RPM4/t/05transaction.t
>
> It runs various tests on the same ts object then calls empty (rpmtsEmpty)
> then run rpmtsOrder() again:
>
> ok(!defined($ts->transreset), "Reseting current transaction");
>
> #ok($ts->transremove($roffset), "Removing pkg from header and offset");
> ok($ts->transorder == 0, "Run transaction order");
>

Ah, right... rpmtsEmpty() is another way of ending up with a NULL pool, 
and one that has subtleties of its own since its called from rpmtsFree() 
as well.

	- Panu -