On Wed, 5 Aug 2020 15:36:53 -0400
Stephen Gallagher <sgallagh(a)redhat.com> 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/[requ...
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-release...
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 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