Le jeudi 27 septembre 2018 à 19:14 -0400, Gerald Henriksen a écrit : > > Or, short version, the Java ecosystem is either indifferent or hostile > to distribution packages. Any language ecosystem is initially hostile to distribution packages. Languages ecosystems are created by devs, that care little about deployment, because 1. they have nothing to deploy at first 2. if they cared about deployment and upgrades, they wouldn't join an ecosystem with no deployment story That initial dev-not-deploy seed tend to imprint the ecosystem culture deeply. And it's worse when you have large business adoption, because businesses want immediate ROI and will pay to have software deployed now even if it takes manual non reusable steps, immature language-specific packages, business-specific no shared tooling, SCL hacks and so on. Thus reinforcing the initial dev conviction they need not bother about deployment and upgrades (note that in that case the "open source free software" gets captured inside the business non open or free bubble because that's the only way to use it in production; and right now Fedora's main sponsor does not care so much about this capture because it has become a business provider). You have to package a large initial baseline of software components, against at best the indifference at worst the hostility of this ecosystem, do much outreaching, before it gets established enough a significant part of the language ecosystem uses it and is convinced the approach is good. You have to be persistent, and try to bridge two tech cultures, and be convinced yourself, because people the other side are waiting for you for give up so they can continue to ignore deployment problems and offload them to (despised) operations. Containers and devops are just another way to collect this huge bag of poop and dump it on someone else. Just take any random container and try to do a security audit of the stuff contained inside the shiny modern enveloppe. Besides the main advantage of distribution packages is upgrade management, and composing of many software components, by tracking the state of each of those components, and providing uniform deployment rules. So you have to wait for years of botched upgrades via other means, and exhaustion of all alternative ways to ignore this tracking by precomposing every possible component mix in separate images, before it becomes evident you need to use distribution packages (and devs are not on the front line for botched upgrades so the realization will not come from the dev side). Note that modules already hit the "too many composition scenarii to precompose everything" wall. That's what caused the back-pedalling on transforming Fedora in a set of independent leaf modules with no distro packages left (but modules-only no distro package little song lingers) There are no special distribution-friendly langages. C∕C++ software was deployed for years without packages on Solaris, AIX, Windows and so on before all the efficiency wins of doing via packages on Linux made Linux distributions capture that market. Many other markets are waiting for a similar distribution moment. For now, addressing them via container, images or modules is not a business handicap, because of the lack of an alternative player. I'm sure they were many meetings at SUN, IBM, HP & Microsoft where the packaging question was raised and someone decided "why bother, it takes money and energy, right now competitors are just as bad as us, devs do not want to deal with the complexity of tracking dependencies, let's look at it later". -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
