https://fedoraproject.org/wiki/Changes/Automatic_Cloud_Reboot_On_Updates
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Cloud users can provide cloud-init metadata when creating a Fedora
cloud instance and that metadata can contain instructions to update
all packages on the system and reboot the system if any of those
updated packages need a reboot to go into effect. Fedora cloud
instances should write the `/var/run/reboot-required` file if a reboot
is needed after a dnf update so that cloud-init can reboot the
instance.
This issue originally surfaced in
[https://bugzilla.redhat.com/show_bug.cgi?id=1275409 RHBZ 1275409].
== Owner ==
* Name: [[User:mhayden| Major Hayden]]
* Email: major(a)redhat.com
== Detailed Description ==
Fedora cloud instances use cloud-init to do the initial configuration
of the instance. This includes setting up networking, assigning a
hostname, adding users/groups, and arbitrary scripts. There are also
two options that you can pass to cloud-init that are important for
this change:
* `package_update`: If set to `true`, all installed packages are
immediately updated on first boot
* `package_reboot_if_required`: If set to `true`, and the
`package_update` step wrote to `/var/run/reboot-required`, reboot the
system immediately after updating packages
📚 For more details, see cloud-init's module reference for
`[https://cloudinit.readthedocs.io/en/latest/reference/modules.html#package-update-upgrade-install
package_update]`.
🚨 '''WAIT A MOMENT. ARE WE TALKING ABOUT REBOOTING EVERY CLOUD
INSTANCE ON BOOT?''' 🚨 No! This change would require all three of
these things to happen before a reboot occurs:
* User provides `package_update: true` on instance creation
* '''AND''' user provides `package_reboot_if_required: true` on
instance creation
* '''AND''' `tracer` notices that at least one of the packages need a
reboot to go into effect
🤔 '''Where does this `/var/run/reboot-required` file come from?''' On
Debian and Ubuntu systems, `apt` automatically writes to
`/var/run/reboot-required` if a reboot is needed after a package
update. From there, `cloud-init` looks for the file
([https://github.com/canonical/cloud-init/blob/6d09df5e4786a2a6c79d6098ab413c…
relevant cloud-init code]) and if present, reboots the system
immediately.
✏️ '''How do we write this file on Fedora?''' Fedora systems have a
package called `tracer` and a corresponding dnf plugin,
`python3-dnf-plugin-tracer`, that analyzes `dnf` updates and provides
recommendations on reboots or user logouts to bring updates into
effect on the system. A recent
[https://github.com/FrostyX/tracer/pull/196 pull request] added
support for writing the `/var/run/reboot-required` file when a system
reboot is recommended. The `cloud-init` tool can read this file after
a package update and reboot if needed.
🔎 '''What does `tracer`'s output look like?'''
[root@tracer-testing ~]# tracer
You should restart:
* Some applications using:
sudo systemctl restart NetworkManager
sudo systemctl restart auditd
sudo systemctl restart chronyd
sudo systemctl restart dbus-broker
sudo systemctl restart qemu-guest-agent
sudo systemctl restart sshd
sudo systemctl restart systemd-journald
sudo systemctl restart systemd-logind
sudo systemctl restart systemd-oomd
sudo systemctl restart systemd-resolved
sudo systemctl restart systemd-udevd
sudo systemctl restart systemd-userdbd
* These applications manually:
(sd-pam)
Additionally, there are:
- 3 processes requiring restart of your session (i.e. Logging out
& Logging in again)
- 1 processes requiring reboot
[root@tracer-testing ~]# cat /var/run/reboot-required
Tracer says reboot is required
📋 '''What do we need to do?''' Add the `python3-dnf-plugin-tracer`
plugin to Fedora cloud images. No additional configuration is
necessary. This action pulls in five packages that are about 2.1MB
after installation:
=======================================================================================
Package Arch Version
Repository Size
=======================================================================================
Installing:
python3-dnf-plugin-tracer noarch 4.1.0-1.fc38
fedora 14 k
Installing dependencies:
python3-dnf-plugins-extras-common noarch 4.1.0-1.fc38
fedora 69 k
python3-psutil x86_64 5.9.2-2.fc38
fedora 271 k
python3-tracer noarch 0.7.8-5.fc38
fedora 172 k
tracer-common noarch 0.7.8-5.fc38
fedora 22 k
Transaction Summary
=======================================================================================
Install 5 Packages
Total download size: 547 k
Installed size: 2.1 M
== Feedback ==
One of the other ideas was to patch `cloud-init` to run `tracer`
directly and avoid the `/var/run/reboot-required` file altogether.
That would require a lot of work upstream in `cloud-init` to enable
the functionality and we would still need the same set of packages
installed in Fedora anyway. 🥵
== Benefit to Fedora ==
This change allows Fedora cloud instances to behave in the same way
that Debian-based instances already behave. When users request package
updates with a reboot now, `cloud-init` performs the update but never
reboots the system. This is an unexpected and confusing result for
users who come to Fedora from other distributions.
Rebooting automatically could also reduce the attack surface of an
instance that just came online since it would immediately reboot to
put all package updates into effect on the system. This reduces the
time that an unpatched instance is online prior to being fully
patched.
== Scope ==
* Proposal owners: This change is fairly isolated and only affects
Fedora cloud users who request package updates followed by a reboot in
their `cloud-init` metadata.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
Since this change only applies to `cloud-init` on the very first boot
of the instance, this wouldn't affect a user upgrading from one
version of Fedora to the next.
== How To Test ==
# Ensure you have a cloud image that has an update that needs a reboot
(kernel, openssl, etc)
# Boot an instance with the following `cloud-init` user data:
#cloud-config
package_update: true
package_upgrade: true
package_reboot_if_required: true
# Wait for the package updates to finish on the instance and verify
that it rebooted after updating
== User Experience ==
First, if a user never uses the `package_upgrade` and
`package_reboot_if_required` options in their `cloud-init` user data,
they won't be affected by this change. These options are not enabled
in `cloud-init` by default.
If a user does enable both of these options, they will see their cloud
instance come online, apply updates, and reboot if required. Most
cloud providers have very fast reboots, so the delay should not be a
problem.
== Dependencies ==
Nothing depends on this change.
== Contingency Plan ==
* Contingency mechanism: Push to Fedora 40 if the work cannot be done in time
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Guidance for users in a blog post (Fedora Magazine) could be helpful
for this change. Many users might not be aware that they had the
option to ask for package updates and reboots via `cloud-init` for
their Fedora cloud instances.
== Release Notes ==
Fedora cloud instances now automatically reboot when a user requests
package updates followed by a reboot on the first boot of the
instance. The reboot only occurs if an updated package requires a
reboot to go into effect (such as a kernel or critical system
library).
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/AspellDeprecation
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Deprecating aspell package because there are better-supported spell
checkers like hunspell/enchant2 which could be used instead. It also
has an upstream with almost 4 years of no action.
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Upstream of the aspell package has been inactive for almost 4 years
now. Most of the packages that have been using aspell in the past did
migrate to the supported [https://github.com/hunspell/hunspell
hunspell package] or any other spell checker.
The plan is simple:
1) Deprecate aspell package.
2) Create Bugzilla tracker to request all packages to be migrated to
the hunspell or any other spell checker (let maintainers choose their
preferred one).
3) After all of the packages have been migrated, create a Change to
retire aspell from Fedora
== Feedback ==
Early feedback from the community is located in this
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Devel list announce])
== Benefit to Fedora ==
Fedora shouldn't maintain a dead package. This change will ensure
Fedora has relevant and upstreamed packages in it's repositories.
== Scope ==
* Proposal owners: Package aspell will be deprecated and the migration
request will be filled as a Bugzilla to all dependent packages
* Other developers: Migrate to hunspell package or any other supported
spellchecker present in Fedora repositories.
* Release engineering: No action required
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
As this is only deprecation change, nothing will need to be handled
manually. The dependent packages will migrate to hunspell or any other
supported spellchecker present in Fedora repositories.
== How To Test ==
== User Experience ==
== Dependencies ==
List of the packages from Fedora 39
=== Requires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep -v 'src$' | pkgname
eiskaltdcpp-qt
enchant-aspell
enchant2-aspell
kf5-sonnet-core
kf5-sonnet-core
moodle
perl-Code-TidyAll
perl-Text-Aspell
php-pspell
qa-tools
recoll
recoll
xedit
xmlcopyeditor
yagf
=== BuildRequires ===
repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
-v '^aspell' | grep 'src$' | pkgname
eiskaltdcpp
enchant
enchant2
hunspell-az
hunspell-csb
hunspell-de
hunspell-en
hunspell-fa
hunspell-gv
hunspell-ky
ibus-typing-booster
inkscape
kf5-sonnet
logjam
perl-MouseX-ConfigFromFile
perl-MouseX-Types-Path-Class
perl-Text-Aspell
perl-Text-SpellChecker
PHP
recoll
tin
xmlcopyeditor
yagf
== Contingency Plan ==
* Contingency mechanism: No contingency mechanism is required for deprecation.
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change by the deadline, it is possible
to just complete this change with the next release.''
== Documentation ==
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in same wiki page, and individual sub changes and devel
threads, with primary reason this - to lower maintenance and still
keep fedora java friendly.
* In first system wide change, we had changed JDKs to build properly
as standalone, portable jdk - the wey JDK is supposed to be built. I
repeat, we spent ten years by patching JDK to become properly dynamic
against system libs, and all patches went usptream, but it become
fight which can not be win
* as a second step we introduced portable rpms, which do not have any
system integration, only builds JDK and pack final tarball in RPM for
free use.
* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated rpms. Instead of this, normal RPMS BUildRequire portable
rpms and just unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latest STS jdk - currently 20, soon briefly 21 and a bit
alter 22... Should be built in latest live EPEL - epel8 now. We have
verified, that such repacked JDKs work fine.
== Feedback ==
== Benefit to Fedora ==
java maintainers will finally some free time... No kidding -
maintenance and *certification* of so much supported JDKs on so much
Fedora versions is brutal. By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS
javas.
If we fail to build once and repack everywhere, java maintainers will
most likely need to lower the number of JDKs in fedora to system one
only.
== Scope ==
* Proposal owners: Technically all jdks (except 8, where some more
tuning is needed, and epels for java-latest) are prepared, as they
have portable version, and rpms just reapck it. Except tuning up the
jdk8 and epel for latest, scope owners are done.
* Other developers: There will be needed significant support from RCM
and maybe senior fedora leadership to help to finish the build in
oldest and enable to repack everywhere<!--
* '''Release engineering: [https://pagure.io/releng/issue/11438
#11438]''' There will be needed significant support from RCM, where
I'm actually unsure what they will have to do to enable this. The mas
rebuild will not be needed.
* Policies and guidelines: AFAIK none (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: All supported JDKS will remain
in Fedora in highest possible quality with full QA and certification,
and its packagers will not lose their minds. note, that QA will still
run on all live fedoras, not only on the builder one.
== Upgrade/compatibility impact ==
The change should be completely transparent to any user.
== How To Test ==
`sudo dnf update/install "java*"` will install expected set of working packages.
== User Experience ==
The change should be absolutely transparent to any user.
== Dependencies ==
To finish this we will need heavy support from RCM, and maybe others.
Although there are precedents with such package, they all bites. From
SW point of view, the dependence chain is `normal RPMs build requires
portable RPMs` and that's all.
== Contingency Plan ==
* Contingency mechanism: It should be stright forward to revert back
to building per OS
* Contingency deadline: N/A
* Blocks release? No. The change can be introduced even on the fly to
live distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
== Summary ==
No longer include `fedora-repos-modular` in default installations.
== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email: <petersen(a)redhat.com>
== Detailed Description ==
The main motivation for this change is to improve the everyday speed
of dnf experienced by Fedora users.
dnf invocations frequently check for and pull down last repo metadata
and the yum modular repos which are seeing less use and content
nowadays have been exasperating this problem.
The proposed solution is just not to install the Fedora modular repo
configurations any more by default.
https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Feedback ==
Some initial discussions:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Benefit to Fedora ==
This change will improve the user experience when updating or
installing packages
since the less-used yum modular repos will no longer be on by default
for all users.
(cf [https://web.dev/why-speed-matters/ why-speed-matters])
== Scope ==
* Proposal owners:
** update F39 comps @core group to not install fedora-repos-modular by default
** update fedora-container-base.ks to not install fedora-repos-modular
** update fedora-common-ostree-pkgs.yaml to not install fedora-repos-modular
** propose Fedora coreos also drops fedora-repos-modular
* Other developers:
** Spin owners may want to check on any possible impact on their
release artifacts
* Release engineering: [https://pagure.io/releng/issue/11426 #11426]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
Any existing modular repos will remain in place and updated normally.
This is also a reason for not changing the modular.repo files themselves,
since disabling the modular repos by default their would cause
upgrades to turn off modular repos.
== How To Test ==
* run dnf upgrade commands etc and check that modular repos are not
active, ie modular repo metadata not checked/downloaded.
* check that fedora-repos-modular is not pre-installed.
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== User Experience ==
Users of new Fedora installations will no longer have the Fedora
modular repos setup and enabled by default,
resulting in a noticeable speed up executing dnf commands.
They can install fedora-repos-modular to activate the modular repos on
their system.
<!-- If this change proposal is noticeable by users, how will their
experiences change as a result?
This section partially overlaps with the Benefit to Fedora section
above. This section should be primarily about the User Experience,
written in a way that does not assume deep technical knowledge. More
detailed technical description should be left for the Benefit to
Fedora section.
Describe what Users will see or notice, for example:
- Packages are compressed more efficiently, making downloads and
upgrades faster by 10%.
- Kerberos tickets can be renewed automatically. Users will now have
to authenticate less and become more productive. Credential management
improvements mean a user can start their work day with a single sign
on and not have to pause for reauthentication during their entire day.
- Libreoffice is one of the most commonly installed applications on
Fedora and it is now available by default to help users "hit the
ground running".
- Green has been scientifically proven to be the most relaxing color.
The move to a default background color of green with green text will
result in Fedora users being the most relaxed users of any operating
system.
-->
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** Change owner(s) will revert the changes and re-enable the modular
repos as needed
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None
== Release Notes ==
* The Fedora modular repos are no longer setup in new installations by
default as of Fedora Linux 39.
* Users can easily enable them with by installing the
`fedora-repos-modular` package.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/AwsCli
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
As a result of the publication of the
[https://bugzilla.redhat.com/show_bug.cgi?id=2189420 awscli2] package,
the original version of 'awscli' is no longer necessary. This would
mark the retirement of the original AWS CLI package version in favor
of the awscli version 2. The AWS CLI version 2 is the most recent
major version of the AWS CLI and supports all of the latest features.
Some features introduced in version 2 are not backported to version 1
and users must upgrade to access those features.
== Owner ==
* Name: [[User:davdunc| David Duncan]] [[User:limb | Gwyn Ciesla]]
* Email: davdunc at amazon dot com, gwync AT protonmail DOT com
== Detailed Description ==
The AWS CLI v2 has been
[available](https://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-general…
for more than 2 years. There has been a considerable amount of
discussion around the decisions made upstream and attempts to create
collaborative efforts with the new Amazon Linux 2023 led to a lot of
discussions related to the supporting libraries included in the
[https://awslabs.github.io/aws-crt-python/index.html AWS Common
Runtime] bindings. It took a long time to find a model that was
consistent and appropriate. A fair amount of effort went into building
this on multiple occasions. Nikola Forro completed work on the package
integration and is actively working on support for packit with the
upstream providers. Since the awscli version is in what we would
consider a maintenance phase, there are many new services and features
that are not available without the awscli2. See the
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.ht…
new features and changes] in the 'Migration Guide' section of the AWS
Documentation for more details on variations in the functionality and
moving your workflow to the later release.
== Feedback ==
== Benefit to Fedora ==
The benefit to Fedora is that users will have access to the most
recent command line tooling for working with Amazon Web Services
features and services. They will have access to new features of the
CLI as well as consistency in the docker and AWS Cloudshell
experiences. That means more consistency in pipeline requirements and
other programmatic access
== Scope ==
* Proposal owners:
Identify the awscli as retired. No additional branches will be built
in support of new releases
* Other developers:
developers will need to review the breaking changes and determine if
they are affected. Issues may require changes to manage pager support
or identify the results encoding where necessary in scripting.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
use of the AWS CLI version 1 in fedora-infra scripts will need to be
tested with the awscli2 prior to the retirement.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
We believe that this is consistent with Community initiatives.
== Upgrade/compatibility impact ==
From the AWS Documentation, the following breaking changes are expected:
* Environment variable added to set text file encoding
* Binary parameters are passed as base64-encoded strings by default
* Improved Amazon S3 handling of file properties and tags for multipart copies
* No automatic retrieval of http:// or https:// URLs for parameters
* Pager used for all output by default
* Timestamp output values are standardized to ISO 8601 format
* Improved handling of CloudFormation deployments that result in no changes
* Changed default behavior for Regional Amazon S3 endpoint for us-east-1 Region
* Changed default behavior for Regional AWS STS endpoints
* ecr get-login removed and replaced with ecr get-login-password
* AWS CLI version 2 support for plugins is changing
* Hidden alias support removed
* The api_versions configuration file setting is not supported
* AWS CLI version 2 uses only Signature v4 to authenticate Amazon S3 requests
* AWS CLI version 2 is more consistent with paging parameters
* AWS CLI version 2 provides more consistent return codes across all commands
== How To Test ==
No special requirements are necessary for testing.
== User Experience ==
The AWS CLI version 2 covers all of the functionality of the version 1
of the AWS CLI. The AWS CLI version 1 is set to be retired in the
future and it would not be beneficial to any of the users to continue
to take dependencies upon it as it is already not the latest version
of the AWS CLI. There are some "breaking" changes from version 1 that
might require you to change your scripts. For a list of breaking
changes in version 2, see
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.ht…
Breaking changes] in the AWS CLI version 2 User Guide.
== Dependencies ==
No currently known dependencies, but an email was sent to the devel
mailing list to provide more visibility for anyone using it actively.
== Contingency Plan ==
In the event that this version is not retired, both versions will be
maintained. The awscli2 already includes a `Provides: awscli`
directive and that would probably need to be removed to ensure that we
distinguish between the two major releases.
== Documentation ==
The AWS CLI v2 provides a
[https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html
Migration Guide] for users who are moving from the AWS CLI version 1
'awscli' to the AWS CLI version 2 'awscli2'.
== Release Notes ==
The 'awscli' package has been retired and replaced with the awscli2.
The awscli2 is the most recent major version of the AWS CLI and
supports all of the latest features. Some features introduced in
version 2 are not backported to version 1 and you must upgrade to
access those features. There are some "breaking" changes from version
1 that might require you to change your scripts. For a list of
breaking changes in version 2, see Migrating from AWS CLI version 1 to
version 2.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Owner ==
* Name: [[User:Otaylor|Owen Taylor]]
* Email: otaylor(a)redhat.com
== Detailed Description ==
There are two types of Flatpak containers -
runtimes - which contain unmodified Fedora packages,
and applications - which contain Fedora packages rebuilt to relocate
them from /usr to /app.
Currently, the rebuild process is done using modules -
packages are either rebuilt in a shared flatpak-common module, or in a
module specific to the application.
This change replaces this with a separate build target that all
rebuilds are done in.
=== Rebuilding RPMs ===
For each Fedora release, we'll have two additional targets
f39-flatpak-runtime (inherits f39), tags: f39-flatpak-runtime-build,
f39-flatpak-runtime
f39-app (inherits f39-flatpak-runtime), tags: f39-app-build, f39-app
The f39-flatpak-runtime target has a limited use -
it's used to build packages that go into the Flatpak runtimes
(standard and KDE).
This would include flatpak-runtime-config, flatpak-rpm-macros,
but also rebuilds of standard packages if needed to prune dependencies:
currently this is done for gstreamer-plugins-good.
The f39-app target is the main target that is used for prefix=/app rebuilds.
flatpak-rpm-macros is part of the build group for this target,
resulting in builds that target /app.
As currently, spec files can be conditionalized with '%if 0%{?flatpak}'
Builds in f39-flatpak-runtime and f39-app have the dist tags
.f39runtime and .f39app respectively.
This is necessary so that we can automatically rebuild a package
without having to bump the release in the specfile.
(Koji requires everything to have a unique NVR.)
It also allows humans and tools to easily distinguish these specialized builds.
Any Fedora packager can rebuild a package into f39-app using 'fepdkg
build --target=f39-app'.
There will also be a new convenience subcommands of fedpkg 'fedpkg
build-flatpak-rpms',
'fedpkg build-flatpak-rpms-local' that can be used to rebuild all
missing bundled dependencies of a Flatpak,
in Koji or locally.
Once a package exists in f39-app or f38-app, then
[[https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync
distrobuildsync]] will be used to do a build into f39-app each time a
standard build completes.
=== Container Versioning ===
Currently, the version is based on the module version:
firefox:stable:3820230427145713:b1edb643 =>
firefox-stable-3820230427145713.b1edb643
Where the module version is created from platform versions and git
commit timestamps
for the module repository.
We could reproduce something very much like this based on the runtime branch and
git commit timestamp, but since application Flatpaks have an
identifiable "Main RPM"
(unlike the general case of modules and containers), a better scheme is:
firefox-112.0.2-1.fc38 => firefox-flatpak-112.0.2-1
name: main RPM name + -flatpak
version: main RPM version
release: automatically incremented based on existing Koji builds
Because upgrades are done on Flatpak ID (org.mozilla.Firefox),
there is no compatibility impact of switching Flatpaks from 'firefox'
to 'firefox-flatpak'.
There is considerable implementation complexity within OSBS to implement this,
because the N/V/R need to be written into generated Dockerfile as
labels ''before'' building it,
but it should be manageable. If not, we'll need to switch to a different scheme.
(Running dnf with <code>--best</code> when building the container will
help make this reliable
and would be a general improvement.)
=== Updates ===
The current plan is that builds of RPMs will be tagged directly into f39-app and
containers will be composed from the contents of f39-app with no
involvement of Bodhi.
Bodhi is only involved in releasing the container.
We can add CI checks on container updates to compare the rebuilt
packages in the container
to the latest released versions for Fedora, though it's not always
easy to distinguish:
* Newer because of a RPM change that hasn't passed testing yet
* vs. Newer because a spec file was needed to get the package to
rebuild with prefix=/app
Since Fedora does not embargo builds,
there's no potential information leak if a change to dist-git is
released via container before it is released by RPM.
=== Disadvantages and issues===
In moving to this system, we lose the ability to take advantage of the
capabilities of modularity -
to use a different stream branch of a library for an application than
the one shipped in F39, say.
There are essentially no examples of this being used in all the
Flatpaks created for Fedora over the last 5 years,
probably because modularity has gained little traction within Fedora
more broadly.
Some Flatpak modules strip down bundled packages by setting macros in
the buildopts/rpms/macros section of the
modulemd file. For example, flatpak-common has:
buildopts:
rpms:
macros: |
%_without_mingw 1
%_without_tkinter 1
This is no longer possible, so these changes need to be fed back into
spec files with
'%if 0%{?flatpak}' style conditionalization.
Additionally a couple of packages (evolution-data-services and
tracker-miners) are set up so they can be
built with an application-specific D-Bus prefix. Evolution has:
buildopts:
rpms:
macros: |
%_eds_dbus_services_prefix org.gnome.Evolution
This will need to be redone so that evolution-data-services doesn't
need recompilation
and the prefixing can be done by changing configuration files at
container build time.
== Feedback ==
== Benefit to Fedora ==
The experience for Fedora developers who want to create Flatpaks of
their applications will be improved:
* They no longer need to understand modularity and modulemd files -
instead of a modulemd file *and* a container.yaml, they simply create
a container.yaml.
* Rebuilds are automatically shared between Flatpaks, without having
to get them added to the flatpak-common module.
* Because the local build experience is no longer using the poorly
maintained local-build mode of MBS, it can be more efficient and
easier to understand.
This should result in more Fedora Flatpaks and more up-to-date Fedora Flatpaks.
We also greatly reduce the usage of Module Build Service within Fedora.
This is important because upstream maintenance is currently reduced,
and it's not clear that we'll be able to sustain a deployment indefinitely.
== Scope ==
* Proposal owners:
** Update flatpak-module-tools to be able to work without modularity
** Create changes to fedpkg to add 'rebuild-flatpak-packages'
(implementation likely within flatpak-module-tools)
** Update atomic-reactor to be able to build Flatpaks without modularity
* Other developers:
** Flatpaks will need to be migrated to the new system by Flatpak
packagers. While we could make the new system opt-in for F39, it's
probably easiest to just require all Flatpaks to be moved over. In
many cases, this should consist of just a few minor changes to
container.yaml.
** Changes to fedpkg and atomic-reactor need to be reviewed, and for
atomic-reactor deployed. '''Note''' Fedora is on OSBS 1, which is not
a current release. Backporting changes to OSBS 1 seems more realistic
than upgrading Fedora to OSBS 2 at this point.
* Release engineering: [https://pagure.io/releng/issue/11415 #Releng
issue number]
** Release engineering will need to manually create the tags/targets
for F39 and update the tag maintenance scripts to do this for future
releases.
* Policies and guidelines:
https://docs.fedoraproject.org/en-US/flatpak/ will need to be updated
once we have an initial implementation. No impact to packaging
guidelines is expected.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: No
== Upgrade/compatibility impact ==
The Flatpaks built will look exactly the same as before from a user perspective.
== How To Test ==
Testing here will be done by selecting a few Flatpaks and trying to
rebuild them using the new system,
first locally and then on infrastructure.
The final validation will be when we mass rebuild Flatpaks for F39.
== User Experience ==
This should be largely invisible to users.
Hopefully, by simplifying the developer experience around creating Flatpaks,
more Fedora Flatpaks will be available and they will be kept more up-to-date.
== Dependencies ==
This is unrelated to other Fedora changes or to changes within packages.
== Contingency Plan ==
* Contingency mechanism: The current infrastructure for module-based
builds will be maintained, so that if we can't get this done for F39,
we'll build Flatpaks as modules for F39.
* Contingency deadline: By 2023-08-01 we should have runtimes built
and a number of applications or we'll plan on using modules for F39
Flatpaks.
* Blocks release? No
== Documentation ==
At the moment, this change proposal is standalone documentation of the
change. As noted above, https://docs.fedoraproject.org/en-US/flatpak/
will need to be updated once we have an initial implementation. If you
are interested in getting involved in planning and implementing this
change, please contact the
[https://fedoraproject.org/wiki/SIGs/Flatpak Flatpak SIG] matrix room.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
Planned Outage - koji database - 2023-06-01 14:30 UTC
There will be an outage starting at 2023-06-01 14:30UTC,
which will last approximately 8 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2023-06-01 14:30UTC'
Reason for outage:
We will be moving the koji buildsystem database (and the virthost it runs on)
to RHEL9 and postgresql 15 (from RHEL8 and postgresql 12).
This outage will happen while the outage of s390x builders is occuring to
consolidate outages. During the outage window koji will be unavailable
and builds will not be possible. After this outage is over, the s390x
builder outage may still be ongoing, so archfull builds may still not
complete until that outage is over.
Affected Services:
koji.fedoraproject.org
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11350
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Planned Outage - wiki upgrade - 2023-05-31 21:00 UTC
There will be an outage starting at 2023-05-31 21:00 UTC
which will last approximately 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2023-05-31 21:00UTC'
Reason for outage:
We will be upgrading our wiki and it's database server along with the virthosts they are hosted on.
Affected Services:
wiki will be unavailable during most of the outage.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11349
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Planned Outage - koji/s390x - 2023-06-01 05:00 UTC
There will be an outage starting at 2023-06-01 05:00 UTC,
which will last approximately 24 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2023-06-01 05:00UTC'
Reason for outage:
The Red Hat Westford location will have more power line work done. This
will require the building to be powered down in places which will affect
various services like network connections and s390x builders.
Affected Services:
koji builds and composes will be affected with builds waiting until the
s390x builders are able to complete the work.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/11345
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren