Inter-WG coordination: Stable application runtimes

Kevin Kofler kevin.kofler at
Sun Jan 12 17:55:54 UTC 2014

Adam Williamson wrote:
> I'm coming to the conclusion that at some point distros have to give up
> swimming against the tide and just say, look, if this is the way this
> ecosystem wants to go, then it's your problem. Fedora's job for such
> ecosystems would simply be to make sure their distribution mechanism
> works on top of Fedora - if it's one we care about - and then butt out.
> I'm not sure we're achieving anything practical for anyone by bending
> PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform
> to Fedora's packaging guidelines (often at the cost that we have to turn
> stuff off, or break stuff, or be months or years behind upstream, or be
> massively incomplete), and I say this as someone who's spent the last
> couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to
> achieve precisely that.

At that point, we can just close shop, we are no longer fulfilling our role 
as a distribution. I also agree completely with Nicolas Mailhot's reply: 
That is NOT what our users want!

Making the software conform to packaging best practices is exactly what we 
packagers are for. It is the only way to deploy software in a reliable, 
well-integrated, secure and space-efficient way. Having multiple competing 
deployment systems on the same machine invariably leads to integration 
issues (where the ones stacked on top can get surprised when a lower-level 
system changes or removes something like a system library, say because the 
user accidentally removed it, not knowing that something outside of the 
system package management requires it). And the security and disk space 
implications of bundling have been discussed many times already.

So, like Matthew Miller, I think we cannot possibly punt on this issue, but 
I totally DISAGREE with his proposed solution of endorsing those bundling 
systems officially. Instead, we need to continue packaging things properly.

        Kevin Kofler

More information about the devel mailing list