On Mon, Aug 7, 2017 at 3:59 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
On Mon, Aug 07, 2017 at 02:10:23PM -0400, Stephen John Smoogen wrote:
> I still don't see how this is going to work with a tree of Service Levels
> and Lifetimes. Any module can not give a SL greater than the lowest SL and
> the shortest lifetime that any package in it is going to agree to. [EG if I
> am packaging up a wordpress module and glibc is on a 18 month lifetime but
> openssl is meh upstream always.. then unless I am going to maintain openssl
> myself with its own fork... my module is going to be 'meh upstream always'.
> If my module pulls in enough stuff to make it work, I am going to be
> dealing with the need of a lawyer to figure out which SL's and lifetimes
> are binding and what ones are not.
Yeah, that would get crazy fast. The 6 month granularity proposal
should help *some*, and we should probably go into this carefully.
For packages, the default is to have fNN branches with the implied 13
month lifecycle and 6 month branch/update window. (Which means that
even nearing the end of the 13 month cycle, there's an overlapping
cycle going half a year longer.)
The Arbitrary Branching proposal suggests not* do this for f28
*automatically (but still allow it). Maybe (at first at least) we need
to say that if packagers want to do *other* cycles, they need to give
at least this "there's a version with an EOL at least 7 months off, and
if you hit it right there's a 13 month window" service level. (That
could be fulfilled by "there's one version that is expected to
continually update in a compatible way".)
Packagers who don't want to deal with all this could just make the
"f28" branch, and packagers who instead want to do something else
longer or additional could.*
Then, we could have an opt-in process (FESCo approval?) for packages
where the upstream changes too fast to support that. (These packages
are presumably problematic in Fedora currently _anyway_.)
* And "longer" sounds like more work, but in many cases it shouldn't
be. I maintain couple of small "leaf" utility programs which are
unlikely to change in a significantly incompatible way, and rather than
maintaining them across "rawhide, f29, f28, f27, el7" I'd like to
maintain just "devel" and "2.stable".
But there's _definitely_ a lot still to work out here!
--
Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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.
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.
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.
I am not saying that updating a brt is not disruptive, but it should not require code changes to my-wp-app just a replacement of the underlying components. However, the disruption is just "dnf module enable brt-f27 && dnf update and reboot. You may, as a user, actually get new binaries in the wordpress-4-on-base-runtime-f27 configuration but the wordpress-4 is built from the same sources and, while not strictly the "same," for 99% of cases they will be.
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).
Langdon
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
