Fedora 33 System-Wide Change proposal: binutils 2.34
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BINUTILS234
== Summary ==
Rebase the binutils package from version 2.33 to version 2.34.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: nickc(a)redhat.com
== Detailed Description ==
Switch the binutils package from being based on the 2.33 release of
the GNU binutils to
being based on the 2.34 release. This release will bring in numerous
bug fixes, as well
as coloured ascii art annotation for the disassembler output!
== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvement to the
linker and assembler.
In addition users who look at disassemblies will find the new ascii
art output quite helpful.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.
* Other developers:
No other work should be necessary. Once the rebase is in place and
the buildroot contains the new binutils its use should be automatic.
* Release engineering: [https://pagure.io/releng/issues/9111] A mass
rebuild will be required.
* Policies and guidelines: No documents need to be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.
== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc. If these packages continue to work then the
binutils update has not
broken anything.
== User Experience ==
The change should not be noticeable to the user.
== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert to the
2.33 binutils as currently used in rawhide. This work can be done by
me, should it prove necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
* Blocks product? None
== Documentation ==
Documentation is not currently available, due to the fact that the
2.34 release has not yet been created.
(It is hoped that the release will happen before the Fedora 33 mass rebuild).
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 Self-Contained Change proposal: Mono 6.6
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Mono_6_6
== Summary ==
Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again
a bootstrap build.
== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpokorra(a)fedoraproject.org
== Detailed Description ==
Even between minor releases, we need to build Mono by doing a bootstrap.
I have successfully built Mono 6.6 without bootstrap, once I have Mono
6.6 installed which was built with bootstrapping enabled.
I would like to request permission to make a one time exception of the
rule for building mono 6.6.0-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
6.6.0-2 using mono-6.6.0-1.
Steps for bootstrapping:
* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 6.x
== Scope ==
* Proposal owners:
Update mono spec and build in koji until it is ready.
Members of the Mono SIG can rebuild their packages with Mono 6.6.
Rebuild of all packages depending on Mono can happen during the
regular mass rebuild.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].
== Documentation ==
* https://fedoraproject.org/wiki/Packaging:Mono
* https://github.com/mono/mono
* https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.6/
* https://github.com/tpokorra/mono-6.x-fedora/tree/master/mono-6.6
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
by Ben Cotton
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: bugzilla(a)colorremedies.com
== Detailed Description ==
Workstation working group has discussed "better interactivity in
low-memory situations" for some months. In certain use cases,
typically compiling, if all RAM and swap are completely consumed,
system responsiveness becomes so abysmal that a reasonable user can
consider the system "lost", and resorts to forcing a power off. This
is objective a very bad UX. The broad discussion of this problem, and
some ideas for near term and long term solutions, is located here:
Recent long discussions on "Better interactivity in low-memory situations"<br>
https://pagure.io/fedora-workstation/issue/98<br>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...<br>
Fedora editions and spins, have the in-kernel OOM (out-of-memory)
manager enabled. The manager's concern is keeping the kernel itself
functioning. It has no concern about user space function or
interactivity. This proposed change attempts to improve the user
experience, in the short term, by triggering the in-kernel process
killing mechanism, sooner. Instead of the system becoming completely
unresponsive for tens of minutes, hours or days, the expectation is an
offending process (determined by oom_score, same as now) will be
killed off within seconds or a few minutes. This is an incremental
improvement in user experience, but admittedly still suboptimal. There
is additional work on-going to improve the user experience further.
Workstation working group discussion specific to enabling earlyoom by default
https://pagure.io/fedora-workstation/issue/119
Other in-progress solutions:<br>
https://gitlab.freedesktop.org/hadess/low-memory-monitor<br>
Background information on this complicated problem:<br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html<br>
https://lwn.net/Articles/317814/<br>
== Benefit to Fedora ==
There are two major benefits to Fedora:
* improved user experience by more quickly regaining control over
one's system, rather than having to force power off in low-memory
situations where there's aggressive swapping. Once a system becomes
unresponsive, it's completely reasonable for the user to assume the
system is lost, but that includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how
to handle them better
== Scope ==
* Proposal owners:
a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
to include earlyoom package for Workstation.<br>
b. Modify {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
to include:
<pre>
# enable earlyoom by default on workstation
enable earlyoom.service
</pre>
* Other developers:
Restricted to Workstation edition, unless other editions/spins want to opt-in.
* Release engineering: [https://pagure.io/releng/issues #9141] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a clean installed system.
== How To Test ==
* Fedora 30/31 users can test today, any edition or spin:<br>
{{code|sudo dnf install earlyoom}}<br>
{{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:<br>
{{code|tail /dev/zero}}<br>
{{code|https://lkml.org/lkml/2019/8/4/15}}
* Fedora Workstation 32 (and Rawhide) users will see this service is
already enabled. It can be toggled with {{code|sudo systemctl
start/stop earlyoom}} where start means earlyoom is running, and stop
means earlyoom is not running.
== User Experience ==
The most egregious instances this change is trying to mitigate:
a. RAM is completely used
b. Swap is completely used
c. System becomes unresponsive to the user as swap thrashing has ensued
--> earlyoom disabled, the user often gives up and forces power off
(in my own testing this condition lasts >30 minutes with no kernel
triggered oom killer and no recovery)
--> earlyoom enabled, the system likely still becomes unresponsive but
oom killer is triggered in much less time (seconds or a few minutes,
in my testing, after less than 10% RAM and 10% swap is remaining)
earlyoom starts sending SIGTERM once both memory and swap are below
their respective PERCENT setting, default 10%. It sends SIGKILL once
both are below their respective KILL_PERCENT setting, default 5%.
The package includes configuration file /etc/default/earlyoom which
sets option {{code|-r 60}} causing a memory report to be entered into
the journal every minute.
== Dependencies ==
earlyoom package has no dependencies
== Contingency Plan ==
* Contingency mechanism: Owner will revert all changes
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
{{code|man earlyoom}}<br><br>
https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
Earlyoom service is enabled by default, which will cause kernel
oom-killer to trigger sooner. To revert to previous behavior:<br>
{{code|sudo systemctl disable earlyoom.service}}
And to customize see {{code|man earlyoom}}.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
== Summary ==
Files in sysusers.d format will be used to declare systems users so it
will be possible to introspect system users. Users will still be
created using old-style useradd calls.
== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl
== Detailed Description ==
Many packages define their own user. Right now, those users are
created in %pre by calling getent, useradd, and groupadd
([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/...
guidelines]). This will be changed to define users in the
[https://www.freedesktop.org/software/systemd/man/sysusers.d.html
sysusers.d format]. A macro will be provided to generate a %pre
scriptlet that will call useradd and groupadd similarly to the
scriptlets that are currently required by the packaging guidelines.
In this proposal, systemd-sysusers will not be used to create the
user. Using the sysusers.d format makes it easy to switch to
systemd-sysusers as the implementation, and to experiment with
different way to actually create the users based on the declarative
syntax.
This approach is heavily based on OpenSUSE's
([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
guidelines]), but does not use separate rpm packages. I think using a
%pre macro is good enough.
== Benefit to Fedora ==
System users are declared by packages using a uniform syntax.
The scriptlet part is standardized. Current implementation of creating
users and groups is not changed, but may be switched easily in the
future. For example, for container images, the macro may be replaced
by a noop implementation, and the users created externally without
installing the user creation tools in the container.
Admins may easily introspect the system user list and which packages
require users.
Admins may easily override definitions of system users by providing
appropriate sysusers.d files with higher priority.
The difference between Fedora and other distros like OpenSUSE is reduced.
== Scope ==
* Proposal owners:
** provide the macro and any helper tools
** submit a proposal to FPC
** convert a subset of packages
* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: convert other packages
* Release engineering: n/a
* Policies and guidelines: a pull request will be submitted
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
None. This change should be backwards and forwards compatible, i.e.
unconverted packages can be still installed on new systems, and
converted packages can be installed on older systems.
== How To Test ==
This change should be mostly invisible to users. During installation,
users should be created as appropriate before packages are installed.
For packages that carry files owned by the user, check that the files
are created with appropriate ownership by rpm.
== User Experience ==
<code>systemd-analyze cat-config sysusers.d/</code>
shows the definitions of system users (incl. local overrides).
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to previous mechanism. This will
require a revert of changes to the spec file and a rebuild of the
package.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
TBD.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: Move fonts language Provides
to Langpacks
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
== Summary ==
Move `Provides: font(:lang=...)` from fonts packages into the
`langpacks` package,
giving predictable default fonts for language scripts.
=== Motivation ===
Currently fonts packages has auto-generated `font(:lang=...)`
provides, which can be used as a dependency identifier to satisfy font
coverage required for a certain language requirement. This is used by
GTK application to install missing fonts via PackageKit for example.
However in practice it has not been very useful since usually there
are assorted multiple fonts that provide the language coverage and so
an arbitrary fonts of unknown quality would get selected, so the
mechanism is not unreliable.
This change uses instead the default fonts chosen in `langpacks` for
each language, to give reliable predictable default fonts for each
language and improve the user application experience around fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
* Email: tagoh(a)redhat.com, pnemade(a)redhat.com
== Detailed Description ==
The language based metadata for fonts packages was introduced in
Fedora 11. The idea being to provide a mechanism to find and install
a font for missing glyphs through PackageKit and was useful for
minority languages which might be missing default installed fonts
packages. But the user experience was generally not terribly good.
Users cannot predict which fonts will be installed. This often leads
to poor fonts choices installed, particularly for languages with too
many available fonts such as English, since the first font found
lexically will be arbitrarily chosen with gurantee of quality or
expected style.
This random dependency resolution sometimes introduces highly
unexpected results too - for example a font from an external
repository may get chosen by chance. This would be particularly
problematic when composing ISOs, eg when including EPEL.
So this Changes proposal aims to improve the user experience around
font dependencies by moving the meta-provides the `langpacks` package
instead. Langpacks contains various dependencies to use for certain
languages, including dependencies for default fonts. so it will
resolve the above issues.
Specifically speaking, currently font provides are generated like this:
<pre>
$ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf
font(dejavusans)
font(:lang=aa)
font(:lang=ab)
...
</pre>
and at the build time, it is transformed to:
<pre>
Provides: font(dejavusans)
Provides: font(:lang=aa)
Provides: font(:lang=ab)
...
</pre>
After this proposal, the above result will be:
<pre>
Provides: font(dejavusans)
</pre>
and then add `Provides: font(:lang=...)` line to corresponding
sub-packages langpacks-core-*.
So asking for a font for a certain language through PackageKit will be
achieved by langpacks-core-* instead of a random font package.
== Benefit to Fedora ==
This proposal will provide reliable, predictable, and consistent font
dependencies.
== Scope ==
* Proposal owners:
** Update fontconfig to drop `font(:lang=...)` from the alias of the
formatter for `%{=pkgkit}`
** Add a line of `Provides: font(:lang=...)` to each
`langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
to be added to `langpacks-core-hi`.
* Other developers: Release Engineers needs to rebuild all fonts
packages with the updated fontconfig package.
* Release engineering: [https://pagure.io/releng/issue/9132 #9132]
* Policies and guidelines: None
* Trademark approval: None
== Upgrade/compatibility impact ==
Some packages may be installed after upgrading if corresponding
langpacks-core-* packages isn't yet installed.
== How To Test ==
# Check that langpacks-core-* provide corresponding `font(:lang=...)`
using `rpm -q --provides`.
# Check that fonts packages no longer provide `font(:lang=...)`.
# Check that langpacks-core-* pulls in the default expected font for
the language.
== User Experience ==
Users should see better fonts chosen for languages when they install a
font to cover a certain language script through PackageKit or through
font meta dependencies of other packages.
== Dependencies ==
All fonts packages
== Contingency Plan ==
* Contingency mechanism: proposal owners will revert all the changes
and rebuild all fonts packages to add back the provides.
* Contingency deadline: the beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: GCC10
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GCC10
== Summary ==
Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 33.
== Owner ==
* Name: [[User:Jakub|Jakub Jelínek]]
* Email: jakub(a)redhat.com
== Detailed Description ==
GCC 10 is currently in stage3, switching to stage4 in January, at
which point it will be in a prerelease state with only regression
bugfixes and documentation fixes allowed. The release will happen
probably in the middle of April. rpms will be built in early January,
but Jeff Law has been testing x86_64 Fedora test mass rebuilds with
GCC 10 snapshots for a while.
== Benefit to Fedora ==
See http://gcc.gnu.org/gcc-10/changes.html for the list of changes.
== Scope ==
* Proposal owners:
Prepare rpms for the new compiler, push them into rawhide, watch
voluntary rebuilds, fix bugs as they are reported, watch fallout from
mass rebuild.
* Other developers: N/A (not a System Wide Change)
Adjust for what will be written in
https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that
will show up after rebuild or report if there are bugs on the compiler
side.
* Release engineering: Perform a mass rebuild, which will be needed
for the LTO System Wide change too.
* Policies and guidelines: N/A (not a System Wide Change)
I don't think so, this is a usual system compiler update that is being
done every year. I think we have skipped GCC 4.2, so in Fedora this
is likely the 15th such System Wide change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No impact
== How To Test ==
GCC has its own testsuite, which is run during the package build, plus
many other packages with automated tests also help to test the new
gcc.
== User Experience ==
Users will be able to see compiled code improvements and use the newly
added features.
Developers will notice a newer compiler, and might need to adjust
their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html,
or, if they detect a GCC bug, report it.
== Dependencies ==
libtool, annobin, gcc-python-plugin depend on exact gcc version, those
need to be rebuilt.
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs. Don't have time to debug issues in 12000+ packages, especially
when in many cases it could be caused by undefined code in the
packages etc. I don't expect we'll have to fall back to the older
gcc, we've never had to do it in the past,
but worst case we can mass rebuild everything with older gcc again.
Jeff Law has performed test mass rebuild on x86_64.
* Contingency mechanism: (What to do? Who will do it?) Revert to
older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
== Documentation ==
http://gcc.gnu.org/gcc-10/
== Release Notes ==
Fedora 32 comes with GCC 10.1 as primary compiler, see
http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: Golang 1.14
by Ben Cotton
https://fedoraproject.org/wiki/Changes/golang1.14
== Summary ==
Rebase of Golang package to upcoming version 1.14 in Fedora 32,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]]
* Email: jcajka(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
1.14 is schedule to be released in Feb 2020.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.
== Benefit to Fedora ==
Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
solid development platform for Go language.
== Scope ==
* Proposal owners: Rebase golang package in f32, help with resolving
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking ticket
https://pagure.io/releng/issue/9136
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a)Install golang 1.14 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.14 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1100.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.13.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.14
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_tra...
== Summary ==
Scriptlets to restart each service that should be restarted in each
rpm package will be replaced by a declaration in the unit file and an
rpm transaction trigger that fires at the end and restarts all
services.
== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl
== Detailed Description ==
Currently, when packages containing systemd services are upgraded,
they are restarted through %post scriptlets in each package. In other
words, the scriptlets specify which services should be restarted and
actually run the command to restart the service. An alternative
mechanism will be provided, whereby the unit file contains a setting
which specifies that the service should be restarted on upgrade, and a
%transfiletrigger in the systemd package will restart all services
marked so in upgraded packages at the end of transaction.
To mark a services as "restart on upgrade" the unit file should
contain an option to mark it so. This can be either in the main
.service file, or e.g. in a drop-in file in
<code>/usr/lib/systemd/system/<service>.service.d/needs-restart.conf</code>.
The exact name of the option should be something like
<code>X-restart-on-upgrade=true|false</code>. I'll take the proposal
for discussion in systemd upstream, since this is something that could
be used across distributions, and then the "X-" prefix could be
dropped and/or the name changed.
== Benefit to Fedora ==
Which services should be restarted is specified declaratively and the
number of scriptlets is reduced.
Admins may easily override this by providing appropriate drop-ins of
their own of higher priority.
Services are restarted after the transaction is finished, all
libraries have been upgraded, and systemd configuration reloaded. This
solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a
more general problem: a service may be restarted before any of its
dependencies (files and static content and whatnot) have been
upgraded, and while some contents from the old rpm are still on disk.
Restarting after all packages have been upgraded avoids this issue.
In the future, restarting of services shall also be extended to user
managers (i.e. to restart all user services after the packages
providing those services have been upgraded). This is not part of this
proposal, but moving the information what to restart into systemd
units makes this much easier.
== Scope ==
* Proposal owners:
** implement the relevant bits in the systemd package
** submit a proposal to FPC
** convert a subset of packages
* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: convert other packages
* Release engineering: n/a
* Policies and guidelines: a pull request will be submitted
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should be backwards compatible, i.e. unconverted packages
can be still installed on new systems, and services will be restarted
on upgrade like before. Converted packages may be installed on older
systems but will not get restarted on upgrades.
== How To Test ==
This change should be mostly invisible to users. Check that during
upgrades services are restarted and that no warnings are emitted.
== User Experience ==
N/A
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to previous mechanism. This will
require a revert of changes to the spec file and a rebuild of the
package.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
TBD.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months
Fedora 32 System-Wide Change proposal: Systemd presets for user units
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
== Summary ==
System units are managed through presets
[https://fedoraproject.org/wiki/Features/PackagePresets since F18] and
by policy, presets are carried by the fedora-release package. This
policy is now extended to user units.
== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl
== Detailed Description ==
The preset mechanism for user units was already in place, but we were
missing the actual preset files, and the default was "enable *"
instead of "disable *" as for system services.
Systemd will now provide a
/usr/lib/systemd/user-preset/99-default-disable.preset that marks user
services as disabled by default. Any user services which should be
enabled will be to get an appropriate preset in
/usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific
file. Most packages already call into the preset mechanism, but those
which don't will be adjusted to do that.
This is essentially a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good
reason to treat user services different than system services in this
regard. On the systemd side this change is very simple, but all
packages that provide user units need to be reviewed to check if they
are enabled after the change if appropriate.
== Benefit to Fedora ==
User and system services are handled in the same way.
Local configuration may be used to override which services should be
enabled after upgrade. In particular, "local" in this context may mean
"per-spin" or "per-user".
== Scope ==
* Proposal owners:
** review all packages that provide user services in Fedora and submit
PRs when changes are needed
** add a new presets file to the fedora-release package for user units
** submit a proposal to FPC to update the guidelines (essentially to
say "... and the same for user services.").
* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: verify that units in their packages are enabled
or not as appropriate after package installation
* Release engineering: n/a
* Policies and guidelines: a pull request will be submitted
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Should not be user visible. Some units which are are currently enabled
by mistake will not be enabled anymore on new installations.
== How To Test ==
Install a new system (or uninstall and reinstall some packages).
Verify that the appropriate units are enabled for the user session.
== User Experience ==
N/A
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the changes.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
A pull request for the packaging guidelines will be submitted.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 3 months