On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote: > On 10/7/19 8:55 PM, Simo Sorce wrote: > > I have to ask, > > given containers are so popular and can deal with any dependency > > without conflicting with system installed binaries, should we really > > continue with this very complicated modular design ? > > There are only few people who fully understand how modularity works > today (contyk who designed modulemd, jmracek and me who implemented the > DNF part and few others). I agree that the modular design should be > simplified. If we don't lower the bar, the complexity might prevent from > wider adoption. Yes, at the moment it is a too complex system. > As a former release engineer, I'm personally unhappy about lack of > upgrade paths between module contexts and I believe that fixing this > part of modularity design could lead to desired simplification. > Unfortunately based on discussion I had with contyk yesterday, I don't > believe it's achievable without making *huge* changes in the modularity > design and the build infrastructure/process. Well, the way I see it, if it is not usable we shouldn't inflict it on users unless there is a clear and overwhelming technical advantage in doing it. So far it eludes me what advantage modularity gives that is so important. > > Shouldn't we go back to have default packages and then defer to > > "containers" for applications (and their dependencies) that need to > > deviate from system defaults for any reason ? > > I don't think containers can replace modularity. They need to coexist. > If we want to create containers built on top of a distribution (no > randomly picked bits from the internet, reproducible builds, security, > ...), we need a way to distribute multiple versions of the software > (module streams) and they frequently need to be built against each other > (module contexts). If modules were just an infrastructure artifact used to build containers (or spins, or any other useful delivery mechanism) I wouldn't be concerned, as then the people exposed to their complexity would be people that know what they are doing and can decide to buy in or not into the modules ecosystem. My main gripe is the current situation where users are thrown under the bus and then we give them a business card and say: read these instruction to figure out how to save yourself. I think this is unacceptable. Simo. > > > Simo. > > > > On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote: > > > Right now, there are two conflicting requirements in Fedora Modularity > > > that we need to resolve. > > > > > > 1. Once a user has selected a stream, updates should follow that > > > stream and not introduce incompatiblities. Selected streams should not > > > be changed without direct action from the user. > > > 2. So far as possible, Modularity should be invisible to those who > > > don't specifically need it. This means being able to set default > > > streams so that `yum install package` works for module-provided > > > content. > > > > > > Where this becomes an issue is at system-upgrade time (moving from > > > Fedora 30->31 or continuously tracking Rawhide). Because of > > > requirement 1, we cannot automatically move users between streams, but > > > in the case of release upgrades we often want to move to a new default > > > for the distribution. > > > > > > > > > The Modularity WG has generally agreed that we want and need to > > > support behavior of the following use-cases: > > > > > > > > > Use Case 1: > > > > > > On Fedora 30, user Alice runs > > > > > > yum install Foo > > > > > > The package "Foo" is provided by a module "foo" with a default stream > > > "v1.0". Because it's available in a default stream, the package is > > > installed and the module stream "foo:v1.0" is implicitly enabled for > > > the system. > > > > > > > > > > > > Fedora 31 is released. On Fedora 31, the module "foo" has a new > > > default stream "v1.1". When upgrading from Fedora 30 to Fedora 31, > > > Alice expects the package Foo she installed to be upgraded to version > > > 1.1, because that's what would have happened if it was provided as a > > > package from the non-modular repositories. > > > > > > > > > > > > Use Case 2: > > > > > > On Fedora 30, user Bob runs > > > > > > yum enable foo:v1.0 > > > > > > In this case, the "v1.0" stream of the "foo" module has a dependency > > > on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0", > > > the system also implicitly enables "bar:v2.4". > > > > > > > > > > > > Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now > > > depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only > > > about "foo:v1.0" would expect the upgrade to complete, adjusting the > > > dependencies as needed. > > > > > > > > > At Flock and other discussions, we've generally come up with a > > > solution, but it's not yet recorded anywhere. I'm sending it out for > > > wider input, but this is more or less the solution we intend to run > > > with, barring someone finding a severe flaw. > > > > > > Proposed Solution: > > > > > > What happens today is that once the stream is set, it is fixed and > > > unchangeable except by user decision. Through discussions with UX > > > folks, we've more or less come to the decision that the correct > > > behavior is as follows: > > > > > > * The user's "intention" should be recorded at the time of module > > > enablement. Currently, module streams can exist in four states: > > > "available, enabled, disabled, default". We propose that there should > > > be two additional states (names TBD) representing implicit enablement. > > > The state "enabled" would be reserved for any stream that at some > > > point was enabled by name. For example, a user who runs `yum install > > > freeipa:DL1` is making a conscious choice to install the DL1 stream of > > > freeipa. A user who runs `yum install freeipa-client` is instead > > > saying "give me whatever freeipa-client is the default". > > > > > > * The state `dep_enabled` would be set whenever a stream becomes > > > enabled because some other module stream depended on it. This state > > > must be entered only if the previous state was `default` or > > > `available`. (We don't want `enabled` or `disabled` streams being able > > > to transition to this state.) > > > > > > * The state `default_enabled` would be set whenever a stream becomes > > > enabled because a transaction pulled in a package from a default > > > stream, causing it to be enabled. This state must only be entered if > > > the previous state was `default` or `dep_enabled`. We don't want > > > `enabled` or `disabled` to be able to transition to `default_enabled`. > > > If a user requests installation of a package provided by a stream > > > currently in the `dep_enabled` state, that stream should transition to > > > the `default_enabled` state (meaning that now the user would expect it > > > to be treated the same as any other default-enabled stream). > > > > > > * When running `dnf update`, if a module stream's dependency on > > > another module changes to another stream, the transaction should cause > > > that new stream to be enabled (replacing the current stream) if it is > > > in the `dep_enabled` state. > > > When running `dnf update` or `dnf system-upgrade`, if the default > > > stream for a module installed on the system changes and the module's > > > current state is `default_enabled`, then the transaction should cause > > > the new default stream to be enabled. > > > > > > * If stream switching during an update or upgrade would result in > > > other module dependency issues, that MUST be reported and returned to > > > the user. > > > > > > This requires some constraints to be placed on default and dependency changes: > > > > > > * Any stream upgrade such as this must guarantee that any artifacts of > > > the stream that is exposed as "API" MUST support RPM-level package > > > upgrades from any previous stream in this stable release. (Example: > > > "freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30 > > > launch. Later updates move this to depending on "pki-core:3.9" and > > > even later "pki-core:3.10". In this case the packages from > > > "pki-core:3.10" must have a safe upgrade path from both "pki-core:3.8" > > > and "pki-core:3.9" since we cannot guarantee or force our users to > > > update regularly and they might miss some of the intermediate ones. > > > _______________________________________________ > > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
