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

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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org