On Tue, Jan 10, 2017 at 8:20 AM, Ian Malone <ibmal...@gmail.com> wrote:
> On 10 January 2017 at 10:08, Florian Weimer <fwei...@redhat.com> wrote: > > On 01/08/2017 01:52 AM, Kevin Kofler wrote: > >> > >> Brendan Conoboy wrote: > >>> > >>> Enhancing interoperability increases the reach of Fedora and doesn't > >>> require a bit of compromise on the the Freedom principle. > >> > >> > >> Splitting a single well-integrated distribution (where all the pieces > are > >> known to work well together) into a bunch of loosely-coupled black-box > >> modules that have no idea what libraries the other modules even contain > >> actually DECREASES interoperability. > > > > > > Only if you do not rebuild each modules from scratch (with the exception > of > > the build tools themselves, but which do not end up in the module). If > you > > do rebuild the module, the build process of each component could be made > > aware what is available in the module, and integrate well with the > features > > which are available. > > > > I think this would resemble what's being done in the embedded space with > > Yocto and BitBake. > > > > Isn't that another problem? Aside from the fact you now need to > rebuild dependencies of each component every time, there's now scope > for package foo to be built with bar-2.1 while faa is built against > bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5. > While having to watch useful programs drop out (occasionally) and be > replaced (or not) because they didn't keep up with the rest of the > ecosystem is a bit annoying, the containerise-everything alternative > means reducing the incentive for programs to keep up to date, > particularly a worry for security issues, but also generally. The > externally nice and shiny container may contain code well past its > use-by-date, this is always my worry when someone suggests containers > as a way around compatibility issues, they have their uses, but they > can also amount to sweeping problems under the carpet. > > -- > imalone > http://ibmalone.blogspot.co.uk > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Exactly, yes, a huge *potential* problem. However, it is fixable with policy and changeable by exception. Just because we can have 40 versions of one thing doesn't mean Fedora will allow that. However, if there is a genuinely good reason and we can track whether that reason continues to exist over time, having the capability is a win. langdon
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
