Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

Kalev Lember kalevlember at
Wed Oct 15 19:54:23 UTC 2014

On 10/15/2014 09:32 PM, Jerry James wrote:
> On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi <kevin at> wrote:
>> * #1350 Updates Policy should require inter-dependent packages be
>>   submitted together  (nirik, 18:15:37)
>>   * LINK:   (nirik, 18:15:38)
>>   * AGREED: Make policy changes now, defer enforcement until later
>>     (+6,0,0)  (nirik, 18:30:03)
> That ticket has already been closed, so I will comment here.  Say that
> I have a package that I want to update, the update breaks somebody
> else's package, and I lack the knowledge to fix that other package.
> How much waiting for the other maintainer am I required to undergo?
> The discussion on the ticket implies that the answer is "an infinite
> amount of time".  Is that really the intent?  Let me present two cases
> where I think "an infinite amount of time" is the wrong answer.

One thing that might not have been clear when reading the FESCo
discussion is that this only applies to the releases where Bodhi is
enabled -- the stable releases (F19, F20) and Branched (F21). It does
_not_ apply to rawhide.

> The first case is when a non-critpath package depends on a critpath
> package.  I've got a concrete example.  I maintain the polymake
> package.  It has its hooks buried deeply into the guts of perl, so it
> depends on the exact perl version it was built with.  Every major perl
> release, without fail, breaks polymake.  Sometimes upstream has
> already noticed and I can update to the latest snapshot to fix the
> problem.  Sometimes upstream has not noticed and I have to ask them to
> produce a fix, which can sometimes take a little while.  If a critical
> perl update were needed, say to fix a glaring performance or security
> problem, and the update broke the polymake build, I think the right
> thing to do would be to push the perl update anyway.  That will break
> things for me and both of the other people who use polymake (hi,
> guys!), but too bad for us.  We can fix polymake as quickly as we can
> and get things back to normal, but we shouldn't block that update from
> going out to all of the people who need it.

We shouldn't get a perl rebase in a a stable Fedora release anyway.
Major Perl rebases are always System Wide Changes and land in rawhide
before the next release is branched.

> The second case is hypothetical, although it is loosely based on an
> actual situation I encountered a couple of years ago.  Say that I want
> to push a non-backwards-compatible update to a library, and that
> packages A, B, and C depend on that library.  I rebuild A and B
> successfully with the new version of the library, but C fails to
> rebuild.  I try to diagnose the problem, but find that C is such a
> horrible mass of spaghetti that I can't make heads or tails out of it.
> So I file a bug against C and wait for the maintainer to respond.  And
> wait.  And wait.  And wait.  At what point am I allowed to push the
> new version of the library, along with A and B rebuilds, and write C
> off as a loss, since I can't fix it and the maintainer isn't
> responding?  Does it depend on the severity of the problem the update
> is intended to fix?  If so, who is the judge of degree of severity?

Pushing out ABI incompatible library versions in a stable Fedora release
isn't something one should do anyway. They should either go in the next
Fedora (rawhide), or if it's important to backport the ABI change to the
current stable release, it's best to introduce a parallel-installable
package for the new library. If an ABI change cannot be avoided, it's
possible to ask for a FESCo exception:

Hope this clears things up,

More information about the devel mailing list