All businesses server uses that matter depend on custom applications and dependencies that are not going to be managed by Fedora itself. Sometimes these applications are developed internally, sometimes externally, sometimes both. They range from everything from perl and shell scripts to huge C++/Java programs with hundreds of dependencies. Everybody's business is different so the logic of the applications need to be crafted to match the business.
Under the current regime of typical application deployment Fedora will have to prove that they can release upgrades that will not break third party binaries and custom applications then this scheme can work.
I don't really think that it's possible unless the application is carefully compartmentalized from the OS in a way to reduce dependencies on Fedora-packaged software to a minimum.
So advice like this:
> Second, we need to ensure Fedora supports the packages people are really using these days. Latest Ruby. Latest OpenStack. Vagrant. Django. Chef. Puppet. All the weird JS stuff that’s popular now on GitHub.
Is actually really really bad. It's never going to work because many times people don't need the latest. Sometimes you need older packages, sometimes newer, sometimes you want to be able to use multiple versions of ruby on the same server for whatever insane reason. It's impossible for Fedora to support this. This approach to packaging software is really quite worthless. It will help the people that always use the latest versions of the software.. ie developers and hobbyists, but it will not be useful for the majority of cases.
The Business needs dictate the application. The Application dictate the dependencies. The dependencies dictate the OS. Budget and time restraints control decisions related to all of this. Trying to package all the dependencies users need so that you are free to do whatever you'd like on the OS side isn't going to be the best approach.
So what Fedora needs to do is develop tools, procedures and work with upstream projects to make it easy as possible for end users to pull directly from upstream repositories (whatever they may be; deb packages, some weird python management tool, tarballs, compile-from-git, etc etc) and make it easy regular users to manage this stuff.
Doing stuff like making it easy to compile software and bundle dependencies (ie: pull in libraries and setup ld path stuff) into something like /opt/application-name_version/ and generate systemd configs to start/stop/status/check logs would be something that would be probably very useful, for example.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds