[Rpm-maint] Planning for rpm 4.13.0 (-rc2)

Panu Matilainen pmatilai at laiskiainen.org
Mon Oct 17 08:05:09 UTC 2016

On 10/16/2016 10:15 AM, Dmitry V. Levin wrote:
> Hi,
> On Fri, Oct 14, 2016 at 04:33:00PM +0300, Panu Matilainen wrote:
>> Hey folks,
>> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll
>> need to cut -rc2 first, there's just too much change to jump right into
>> final.
>> The idea is to get -rc2 out next week (ie by Oct 21st at latest). If all
>> goes well we'll just rename that to -final in a few weeks time, if all
>> goes to hell we'll just have another -rc. Which I really, really dont
>> want to happen. So what I've planned for -rc2 is this rather
>> conservative cherry-picks from git master on top of the 4.13.x branch:
> [...]
>> Anyway, the list above is not set in stone, otherwise there'd be little
>> point in posting it here. If you think something absolutely critical is
>> missing from that list, or that something should not be there, now is
>> the time to speak up.
> Please include rpmdb.c fixes (commits 4c6e51e2 and e5d3b9f6), they are
> essential for apt-rpm.

Request noted, but remember this is an ages old runtime bug, finally 
fixed. Whether it gets fixed or not does not affect eg package or 
API/ABI compatibility, so it can just as well be fixed in 4.13.1.

I guess I should've explained myself more clearly. What makes a MUST-FIX 
in this situation is quite specific. Here are the main categories with 
some examples that hopefully make it clearer:

a) things that affect file formats (package compatibility etc)
    - d20b7d2 Fix rpmrichOpStr to use the new syntax
    - 7a84b45 Add support for various types of dependencies to
      rpmdeps tool
    - 61838b0 Remove size limit when expanding macros
    - 19fe0d9 Add posix.redirect2null

b) things that affect API/ABI
    - aee8446 Rename expandMacrosU to rpmExpandMacros
    - ddf9ec7 rpmExpandMacros() is modified to be able to return
      more return codes

The common theme in the above being that not fixing now would somehow 
make life harder in the future, or break things that people are already 
depending on in their specs etc (due to Fedora and Mageia and having 
these patches for a long time). These are *the* kind of things I'm 
asking for more eyeballs on.

Then there are SHOULD-FIX items, which are just runtime bugs and such 
that could be fixed at any later release as well. However at this point 
not fixing the reported security issues would look seriously strange and 
bad, so they are essentially must-haves. And we dont want known 
regressions from 4.12.x either:

c) security fixes
    - 1af568a Fix next_brace_sub() to return NULL if braces don't match

d) regressions from 4.12.x
   - 0d214a1 Permit scriptlet exec context setting to fail in
     non-enforcing modes

Then there are various other upstream backport patches in Fedora and 
Mageia for a long time that do not really match the above, but dropping 
them would basically introduce regressions and force the distros to 
carry those patches with no good reason. Plus the 4.13.x codebase is 
actually most tested with those particular patches applied, whether they 
are otherwise that important or not so dropping those patches is 
actually more risky than not doing so.

	- Panu -

More information about the Rpm-maint mailing list