Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/10/2017 11:49 AM, Matthew Miller wrote:
On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
Apache httpd and KDE are very interesting examples.  Both KDE and
Apache httpd integrate with Subversion, on two levels: KDE has
Subversion client support, Apache httpd has server support.  And
Subversion is implemented using apr (the Apache Portable Runtime
library).

So unless we start building Subversion twice, once for use with
Apache httpd, and once for use within KDE, modules containing KDE
and Apache httpd will have to agree on the same version of
Subversion and the same version of apr.  To cut down support
overhead, we'd probably want them to use the same versions, too, but
this might not always be possible (e.g., newer upstream versions may
have obliterate support, which would be considered an important
server-side feature, but also change the working copy format, which
would not be acceptable for a stable desktop release).

Thanks, Florian - that's a great example. This is an area where Fedora,
in our well-meaning attempt to integrate everything, has hobbled
ourselves compared to more focused distributions. A project like Solus
can focus on just the desktop case and doesn't have to care about
Apache as an actual server; a server-only distro can make the opposite
choice. In Fedora right now, someone has to lose. Modularity gives us
flexibility to make a different decision on a case-by-case basis.

We can deal with this in Fedora today, and we do:

mozjs17.x86_64 : JavaScript interpreter and libraries
mozjs24.x86_64 : JavaScript interpreter and libraries
mozjs31.x86_64 : JavaScript interpreter and libraries
mozjs38.x86_64 : JavaScript interpreter and libraries
mozjs45.x86_64 : JavaScript interpreter and libraries

Plus the copies in Firefox and Thunderbird at the very least.

The Spidermonkey Javascript implementation is probably not such a great example because there is a lot of development, but for other projects with API/ABI changes, but without so many internal changes, it would be nice to have a way to build slightly different upstream versions with the same pile of patches applied on top.

Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux