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
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
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.
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
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.
Enable module default streams in the buildroot repository for modular
and non-modular RPMs.
== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
* Responsible WG: Modularity WG
== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.
Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.
Note: This Change does not address the other major Modularity issue we
are facing around distribution upgrades with differing default
streams. When discussing this Change, please keep that topic separate.
== Benefit to Fedora ==
This will simplify the lives of package maintainers in Fedora in two
primary ways. I'll use a hypothetical example of the Node.js
interpreter and a JSApp package which is capable of running on Node.js
10 or 12 (but requires newer features than are provided by Node.js 8).
Additionally, the JSApp package requires the same versions of Node.js
* Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F31 lifetime.
* Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F32 lifetime.
On Fedora 29 through 31, the Node.js package maintainer needs to build
the `nodejs:10` package both as a module and as a non-modular RPM in
the distribution so that the JSApp package can be built. With this
Change, the Node.js package maintainer in Fedora 32+ will only need to
build the various Node.js streams and make one of them the default
stream. The packages from it will then be added to the buildroot for
non-modular packages. This will also make the packaging process
somewhat more efficient, as the maintainer needs only to manage the
module stream and the MBS will build it for all configured platforms.
Similarly, from the perspective of dependent maintainers, there will
no longer be anxiety about needing to move their package to a module
if one or more of their dependencies drops their non-modular version
in favor of a default stream. Their builds will continue to work as
they do today.
== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot
* Other developers:
Packagers of default module streams will be required to conform to the
regarding visibility of stream artifacts. Any default module stream
that is not in compliance by one week before Beta Freeze will cease to
be a default stream.
* Release engineering:
# https://pagure.io/releng/issue/8879 - Create pungi config for
Rawhide/F32 ursa prime buildroot
# https://pagure.io/releng/issue/8880 - Include
`default_modules_scm_url` in platform 31 virtual module
# https://pagure.io/releng/issue/8881 - Configure Koji tags for
* Policies and guidelines:
The Modularity Packaging Guidelines will need to be updated to
indicate the strict requirements on default streams.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change is on the build-system side of things and should not
impact the upgrade process directly.
== How To Test ==
# Build a modular stream
# Make that stream a default stream (or a buildroot override)
# Build a non-modular RPM that requires an artifact RPM from the modular stream.
== User Experience ==
This should not change the end-user experience.
== Dependencies ==
Nothing known that isn't listed in the scope.
== Contingency Plan ==
* Contingency mechanism: Disable the buildroot inheritance in Koji to
revert to the current behavior.
* Blocks release? Ambiguous: lack of complete implementation may
indirectly cause blocking issues.
* Blocks product? No
== Documentation ==
== Release Notes ==
None needed, the Change is not user-facing.
He / Him / His
Fedora Program Manager
I am in the process of building a new version of suricata, and IDS program
that watches network traffic. It has a new module that uses eBPF for high speed
network packet categorization. When building, it uses the following command:
/usr/bin/clang -Wall -Iinclude -O2 \
-D__KERNEL__ -D__ASM_SYSREG_H \
-target bpf -S -emit-llvm xdp_lb.c -o xdp_lb.ll
It eventually includes /usr/include/features.h which in turn includes
/usr/include/gnu/stubs.h. That file has this code:
#if !defined __x86_64__
# include <gnu/stubs-32.h>
I don't think __x86_64__ is defined as the program is aimed at eBPF in the
kernel. In rawhide, we no longer have glibc-devel(x86-32) to allow this to
resolve. However, I think that the assumption of not having __x86_64__
defined means we are targeting i686 is wrong. What should I do? Do we not
support eBPF programs on Fedora?
Can you specify which packages are the A & B?
I wanted to reproduce the initial situation - that the service
requiring another will put a symlink to the "/usr/lib/systemd/system".
I forged iptables RPM containing service file mentioning
"Requires=firewalld.service" to see the link to be created, but it
(iptables because it builds fast and firewalld because it is already installed)
I wanted to run audit on the location to catch a process which would
create the symlink, in a hope that it won't be systemd itself, but
rather some systemd helper script, which name would be good starting
point for google.
( "auditctl -w /etc/systemd/system/" and "ausearch -f /etc/systemd/system/" )
Core Services - Databases Team
On Sat, Oct 12, 2019 at 8:12 AM Ravindra Kumar via devel
> > You need something like this in a scriptlet:
> > if systemctl is-enabled A; systemctl reenable A; done
> > This will remove the old links and create the new ones.
> Thanks Zbigniew for the idea. It seemed very promising and I tried it. Unfortunately, it still did not help because "reenable" command seems to recreate the links based on the service unit file which is newer and does not reference the dropped dependency. So, the old link to service B was still left around.
> The only working solution I have found is to disable service B explicitly in post install scriptlet when it is called during upgrade.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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://email@example.com
I haven't heard anyone mention FOSDEM yet. Booth applications are due soon
and I'd like to see us coordinate again with our friends in CentOS. Is
there anyone interested in owning this? If so, can you put together a
proposal for Mindshare?
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com | bex(a)pobox.com