On Mon, Aug 07, 2017 at 11:48:53PM +0000, Langdon White wrote: > I guess I am not sure how this is different with modules than with Fedora > today. We promise a 13 month lifecycle on openssl (and everything else) > already. I think the difference here is only that the "position" is > explicit. However, this is not the "real" point to my reply. Well, right now, that implicit SL/lifecycle is the same for every package -- or given a specific exception https://fedoraproject.org/wiki/Updates_Policy#Exceptions. If we add the ability to make it explicit, we need to now be clear on which choices are acceptable in Fedora. If we make it "you've got to have the exact SL and lifecycle as always before", we lose quite a bit of the power. If we make it "sure, go EOL every two weeks with your core package!" we lose the benefit of being a distro at all. > I agree it is true that the lifecycle of a given *binary* is locked to the > lifecycle of the module binaries it depends on. However. this does not > necessarily mean that a *stream* is locked to the those lifecycles. In > other words, wordpress doesn't expose glibc or openssl APIs to its > consumers (to my knowledge ;) ). As a result, it is perfectly valid for the > wordpress-4 stream to be built against base-runtime-f26 (brt) or > base-runtime-f27 or both. If the lifecycle of base-runtime-f26 runs out, > that doesn't mean wordpress-4's lifecycle has run out, it just means that > the user must upgrade the base-runtime stream but their application that > relies on the wordpress-4 API will continue to operate unchanged. Sure. But from a user point of view, if this juggling happens on arbitrary dates many times throughout the calendar year, we've just delivered something with all the disadvantages of a rolling release *plus* a lot of extra complication. But let's not even go that far out. Just within base runtime itself, there are hundreds of packages. If *those* are aribitrarily EOLing all the time, the maintainers of the base runtime module are going to have to spend significant time juggling that. As what I read this.... > As we are able to increase the bundling of components, the 99% continues to > add 9s after the decimal. At present, we must consume the openssl-1.1 > branch in brt/shared-userspace because dnf/rpm can't tell that the binaries > provided by different modules are functionally the same. However, as we > improve that or find other methods around this problem (private > namespacing, containers, rpathing, etc), we could have the openssl-1.1 > sources in dist-git be included in multiple modules. When the openssl > maintainer elects to add the openssl-1.2 stream, wordpress-4 could decide > if it is appropriately backwards compatible for their use case and consume > it (by changing their modulemd to point to the new stream). ... a lot of that juggling is going to be discovering every week that some important component has shifted and now the module maintainers need to find someone to maintain a compat branch of the older package. That could include packages which are just under the hood but incompatible or could be packages which have a knock-on effect and change the exposed module API. Following all of this seems like an unrealistic explosion of work. Right now, if I want to maintain Apache, I can rely on the 13-month implicit API for OpenSSL. I can concentrate on the thing I have expertise and interest in and trust that others in the community have made commitments for the dependencies. It's great that modularity offers me the ability to take on more if I want to, but if I *have* to in order to make a module with even the same promises as current Fedora, that's worrisome. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
