On Wed, 5 Aug 2020 15:36:53 -0400 Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > = Policies Regarding Modules in Fedora, Fedora ELN and EPEL I find that all the discussion of non-ELN Fedora and EPEL distract from the subject of ELN. The proposal would be clearer if it restricted itself to ELN and left non-ELN fedora for a separate proposal. I also have several questions that the proposal does not address. I believe that modularity has fundamental deep and hard design problems. My evidence for this is the several years of FESCO tickets. Many of these tickets were not resolved or resolved only with hacks, eventually compelling FESCO to restrict the scope of modularity. I am skeptical that these issues can be solved at the policy level. Please go back to the drawing board and don't push modularity at us until they're fixed. > == Requirements for All Module Streams > * The module maintainer *MUST* have explicit commit privileges to all > packages included in the module stream. The provenpackager privilege > in Fedora is not sufficient.footnote:[This ensures that the package in > the module is being maintained by someone responsible for it.] > * Components built into a module *MUST* be associated with a reachable > commit in Fedora dist-git.footnote:[There are legal and licensing > requirements for reproducibility of builds.] > * If a stream of a module has build-time-only components, all such > components *MUST* be marked as `buildonly: True` in the module > metadata to avoid shipping them to users and polluting their > repository. I think that build-only components are antithetical to Fedora's "Friends" foundation. It interferes with my ability to consume, rebuild, and modify the affected packages. I would like to see build-only content forbidden except for well-defined situations. This is especially important for default modules. Proposal: Build-only content is forbidden in default modules and is permitted in other modules only with FESCO exception if no other solution is possible. > == Requirements for Default Streams > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > permits defaults streams that adhere to the policy below. This is supposed to be a policy for ELN, yet this is the last time ELN is mentioned. I am unsure how the following is supposed to apply to ELN. > * All RPMs in default module streams are required to conform to the > same > https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/[requirements > around Conflicts] as non-modular RPMs. > * Packages provided at runtime by the default stream of a module > *MUST* depend only on packages provided by packages from default > module streams or the non-modular package set. By extension, default > streams of a module *MUST NOT* have a dependency on any non-default > stream.footnote:[It is highly recommended that default streams have no > module dependencies besides the platform to avoid potential future > conflicts during upgrades.] > * Packages provided from default streams *MAY* depend on content from > other default streams. If they do so, this dependency *MUST* be > encoded in the module metadata.footnote:[This is so that if the > maintainers of either module wishes to change its default stream, it > is easy to see what other modules would be impacted and coordinate > it.] > * All packages provided at runtime by the default stream of a module > *MUST* provide all the same functionality that a downstream consumer > would expect from a package in the non-modular package > set.footnote:[If a package is not filtered out from the default module > stream, it is going to be part of the default-available content and > therefore must be treated (and supported) just like a non-modular > package.] > * The default stream of a module *MUST NOT* change to a different > stream within a released Fedora version.footnote:[This is an extension > of the > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases[stable > updates policy].] The default stream *MAY* be changed in Rawhide or > during Fedora upgrades. Changes to default streams *MUST* be approved > via a > https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process[Fedora > Change proposal]. And what about ELN? What standards apply to judging the change proposal? > * Packages *MAY* convert from a non-modular package to a modular > default stream (or the reverse) only in Rawhide or during Fedora > upgrades. And what about ELN? Will this also need a change proposal with FESCO approval? > * Default streams *MUST NOT* provide a binary RPM with the same > package name as a non-modular RPM in the same release except in the > case of a transition from one to the other.footnote:[Modular packages > shadow non-modular ones. This rule ensures that we don't have any > shadowed packages in the default package set.] > * Default streams *MUST NOT* provide a binary RPM with the same > package name as an RPM in a default stream in the same release except > in the case of a transition from one to the other.footnote:[In this > situation, whichever has the highest NEVRA would win the depsolving > and could break the other module.] > * Multiple default streams *MUST NOT* provide the same binary package > names at runtime.footnote:[They *MAY* provide other well-known names > in the same manner as permitted for non-modular content. For example, > two different default streams *MAY* provide content to be used with > the `alternatives` system or virtual `Provides` for capabilities.] > * Default streams *MUST NOT* provide a package that overrides a > package of the same name in the non-modular content except in approved > cases of migration between modular and non-modular delivery. Approved by whom? > * Default streams *MUST NOT* use the `data.buildopts.rpm.macros` > metadata section without approval by FESCo.footnote:[This feature > allows for overriding the standard macros for building packages in > Fedora and should be avoided entirely for default streams so they are > built just like non-modular packages.] Also, what is the relation between ELN and rawhide? Are ELN default modules built from the same sources as the rawhide non-modular content? What if patches are needed or useful? Do ELN default modules have identical non-default rawhide modules? What happens when the rawhide package is rebuilt or upgraded? What if the upgrade is not compatible with a ELN default module? Are rawhide maintainers supposed to care about the corresponding ELN default modules? Are rawhide maintainers supposed to care about dependent ELN default modules? Are rawhide maintainers allowed to "clean up" their spec files to remove ELN "clutter"? What infrastructure tooling exists or is needed to implement this proposal? Can it be implemented in a timely manner. I recall several requests for tracing modular dependencies, which could not be answered easily. Has that been fixed? What is the current state of modularity with respect to .so name bumps, mass rebuilds, and orphaned and retired packages? How are users supposed to install ELN and test it and it modules? I understand ELN is not producing installers. This is not part of the policy, but it is still relevant, because the ELN as a test bed will be much more meaningful if ELN can be consumed at least as easily as rawhide. How are users and 3rd party packagers supposed to rebuild modular content? Where are the docs? As a user I consider this a hard requirement, and ask that FESCO do the same. How are users and 3rd party packagers supposed to build RPMS that depend on modular content? Where are the docs? As a user I consider this a hard requirement, and ask that FESCO do the same. Thanks, Jim _______________________________________________ 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
