Wiki - https://fedoraproject.org/wiki/Changes/Authselect_Hardcode_Altfiles
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-hardc…
This is a proposed Change for Fedora Linux.
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 ==
Currently, authselect users can enable nss-altfiles in nsswitch.conf
using "with-altfiles" feature. This proposal is to remove the feature
and hardcode nss-altfiles support in nsswitch.conf in all shipped
profiles, making it required.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrezina(a)redhat.com
== Detailed Description ==
Currently, non-ostree systems (e.g. Fedora Workstation) have
nss-altfiles nsswitch.conf module optional in authselect profiles.
Users can enable this module by calling "authselect enable-feature
with-altfiles" or directly when selecting the profile "authselect
select $profile with-altfiles".
However, the nss-altfiles nsswitch.conf module is required to be
enabled on ostree systems (e.g. Fedora Silverblue) and must not be
disabled there to make system users available to the system. This is
currently handled by authselect in %post scriptlet that modifies the
shipped profiles and hardcodes nss-altfiles in them.
This solution, however, makes authselect different on ostree and
non-ostree systems. The history also showed that it is quite fragile
and easy to break with modifications to the profiles. The intention is
to hardcode nss-altfiles on both ostree and non-ostree, making
authselect install exactly the same files on both distribution types.
== Feedback ==
None.
== Benefit to Fedora ==
Both ostree and non-ostree Fedora releases will ship exactly the same
authselect content.
== Scope ==
* Proposal owners: Do the work in upstream and release it in Fedora.
* Other developers: None.
* Release engineering: None.
[https://forge.fedoraproject.org/releng/tickets/issues #Releng issue
number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
None. Upgrade path will be handled by authselect.
== Early Testing (Optional) ==
== How To Test ==
1. Check that with-altfiles is no longer available in the profiles
2. Check that "altfiles" is present in generated /etc/nsswitch.conf
== User Experience ==
User's should not notice the change.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The "with-altfiles" feature has been removed from all authselect
profiles. The nss-altfiles support is now enabled and can not be
disabled.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Authselect_Remove_NIS_Profile
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-remov…
This is a proposed Change for Fedora Linux.
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 ==
Authselect currently ships four profiles local, sssd, winbind and nis.
This change suggest removing the nis profile from authselect - it will
no longer be possible to configure nsswitch.conf for NIS with
authselect using "authselect select nis" but NIS will still be
available on the system and users will be able to configure their
nsswitch.conf to use NIS with custom authselect profile or manually.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrezina(a)redhat.com
== Detailed Description ==
This change will remove the authselect nis profile from the list of
shipped profiles. User's will no longer be able to choose this profile
to configure their nsswitch.conf for NIS support. They will need to do
it manually or with a custom authselect profile.
== Feedback ==
No feedback.
== Benefit to Fedora ==
NIS is an old, outdated technology. This change does not strip NIS
support from the system, only from authselect profiles. Vast majority
of the Fedora users should not be affected and user's that still
require NIS will still be able to use it. Reducing number of profiles
will make authselect maintenance easier.
== Scope ==
* Proposal owners: Remove NIS profile from authselect RPM and from
authselect upstream.
* Other developers: None
* Release engineering: None.
[https://forge.fedoraproject.org/releng/tickets/issues #Releng issue
number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
User's that have the nis profile selected will still have the system
configured correctly after upgrade. But "authselect check" will report
issues.
== Early Testing (Optional) ==
== How To Test ==
check that `authselect list` no longer shows nis
== User Experience ==
Authselect nis profile is no longer available.
== Dependencies ==
== Contingency Plan ==
Revert changes if needed.
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The "nis" authselect profile was removed. If you use this profile,
make sure to create and select a custom authselect profile that will
enable nis support on your system or opt-out from authselect with
"authselect opt-out", keeping the current configuration intact.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/CoreOS_default_to_enable_systemd-oom…
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-enable-systemd-o…
This is a proposed Change for Fedora Linux.
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.
= Enable systemd-oomd and zram swap for CoreOS =
{{Change_Proposal_Banner}}
== Summary ==
Enable systemd-oomd.service and swap on zram by default to align
Fedora CoreOS with other Fedora variants.
== Owners ==
* Name: [[User:Nemric| Nemric]]
* Email: emeric at i-chassagne dot fr
* Name: [[User:jbtrystram| jbtrystram]]
* Email: jbtrystram(a)redhat.com
== Detailed Description ==
Enable `systemd-oomd.service` and swap on zram in CoreOS by default as
it's done in other Fedora variants.
This was historically disabled because Kubernetes was not compatible
with swap on nodes until recently
[https://kubernetes.io/docs/tutorials/cluster-management/provision-swap-memo…
(provision-swap-memory)]. As CoreOS targets container workloads
it made sense to aim for a better kubernetes experience.
Note that this will not only affect new installs, but also existing
running nodes.
See more discussion in
https://github.com/coreos/fedora-coreos-tracker/issues/840 and
https://github.com/coreos/fedora-coreos-tracker/issues/859
== Feedback ==
The change author (Nemric) have been using swap on zram since years
now, and kubernetes is working great with that.
He also enabled `systemd-oomd.service` months ago without issues with
the following kubelet config:
<pre>
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwap
</pre>
== Benefit to Fedora ==
That will reduce the CoreOS configuration as we would simply inherit
what's default in Fedora. This is a reduction in maintenance work.
== Scope ==
* Proposal owners:
** Remove the overrides from the config
** Write a release-notes entry detailing the change.
== 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? -->
This change will affect all nodes then, take care of apps that won't
accept swap as default behavior like kubernetes
see [[Changes/CoreOS_default_to_enable_systemd-oomd_and_swap_on_Zram#Feedback|Feedback]]
== How To Test ==
see https://fedoraproject.org/wiki/QA:Testcase_CoreOS_swap_on_zram
== User Experience ==
== Contingency Plan ==
Disable the service in the next release and ship a migration script to
turn it off for nodes that were deployed with the service active.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Sequoia_opengpgverify
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-sequoia-opengpgv…
This is a proposed Change for Fedora Linux.
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 ==
Introduce a rpm macro <code>%openpgpverify</code> and update packages
to use it instead of existing gnupg specific <code>%gpgverify</code>.
The new macro will use standard OpenPGP implementation from Sequoia
instead of GnuPG by default to provide support for Post Quantum
Cryptography defined in the OpenPGP WG. This is part of gradual
switching from GnuPG dependency.
== Owner ==
* Name: [[User:jjelen| Jakub Jelen]] [[User:decathorpe | Fabio Valentini ]]
* Email: jjelen(a)redhat.com, decathorpe AT gmail DOT com
== Detailed Description ==
The GnuPG decided to fork the OpenPGP specification as LibrePGP to
develop incompatible standard in 2023. Since then, the GnuPG 2.5.*
versions (not present in Fedora) can create artifacts incompatible
with current OpenPGP standard. We are observing the situation and the
we believe Fedora project should embrace the OpenPGP standard
developed within the IETF, which involves gradually switching from the
GnuPG to other implementations where possible.
We identified Sequoia-PGP as a good candidate as it implements the
standard OpenPGP (including the RFC 9980 standardizing PQC). The
Sequoia-PGP is already used as part of RPM to verify
[https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ RPM signatures]
since 2023, as well as in
[https://src.fedoraproject.org/rpms/rust-podman-sequoia podman]. RPM
also supports [https://github.com/rpm-software-management/rpm/blob/master/docs/man/rpmsign…
signing RPMs using Sequoia tools] since version 6.0 so adjusting the
rpm macros is natural next step.
== Feedback ==
== Benefit to Fedora ==
* Prevent vendor-lock-in in GnuPG ecosystem.
* Follow IETF standardization
* Improve security by providing developers with ability to use Post
Quantum Cryptography to sign their artifacts.
* Integrate better with the rest of the operating system by following
system wide crypto policies.
== Scope ==
* Proposal owners:
* Create a new <code>%openpgpverify</code> macro using sqv CLI
* Verify it works with existing artifacts in Fedora,
fix/workaround/report possible issues.
* Change <code>%gpgverify</code> rpm macro in existing spec files to
use <code>%openpgpverify</code> where possible with proven packager or
PRs
* Other developers: Respond to possible issues/PRs in cases where this
will not work out of the box.
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues #Releng issue
number]
* Policies and guidelines: The Packaging Guidelines should be updated
to make use %openpgpverify macro by default.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A
== Upgrade/compatibility impact ==
No upgrade impact -- this involves just build system and development.
Compatibility needs to be evaluated. There should not be any existing
librePGP artifacts, but there might be some old GnuPG keys that will
not pass stricter Sequoia checks. Identifying them will help increase
security of the supply chain as insecure keys might allow getting
forged artifacts to Fedora.
== Early Testing (Optional) ==
Verify all packages that use <code>%gpgverify</code> macro work with
<code>%openpgpverify</code>.
== How To Test ==
* Have a dist git of a package with upstream tarball signed with GPG key
* Update gpgverify BuildRequires to openpgpverify
* Update %gpgverify macro to %openpgpverify
* Verify the local package build works for you with `fedpkg local` or
`fedpkg mockbuild`
If not, review the log, key(ring) and report potential issues to the
upstream developer or Sequoia developers. Do they use SHA1 in their
certificate? Do they use small RSA key that could be broken by Quantum
Computer in close future?
== User Experience ==
This change should not affect user experience.
== Dependencies ==
* rust-sequoia-sqv
* gpgverify
* other packages using gpgverify
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
Fedora packaging guidelines need to be updated to reflect this change.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signa…
N/A (not a System Wide Change)
== Release Notes ==
Fedora is using Sequoia to by default to verify upstream tarball
signatures during the build time. This allows upstreams to sign their
artifacts using Quantum Resistant algorithms defined in the latest
OpenPGP RFC 9980.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/ODBC_stack_modernization
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-odbc-stack-moder…
This is a proposed Change for Fedora Linux.
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 ==
Modernize the Fedora ODBC stack across 7 packages
(<code>unixODBC</code> and 6 driver packages:
<code>mariadb-connector-odbc</code>,
<code>mysql-connector-odbc</code>, <code>postgresql-odbc</code>,
<code>freetds</code>, <code>sqliteodbc</code>, <code>mdbtools</code>).
The central change is replacing the static, centrally-maintained
<code>/etc/odbcinst.ini</code> driver registration file with an
auto-generated configuration assembled from per-driver drop-in
snippets, using RPM file triggers — the same pattern used by
<code>ldconfig</code>, <code>ca-certificates</code>, and
<code>crypto-policies</code>. Supporting changes include switching to
bare library names resolved via a compiled-in search path, moving
driver plugins to a dedicated directory, and general spec cleanups.
== Owner ==
* Name: [[User:mschorm|Michal Schorm]]
* Email: mschorm(a)redhat.com
=== Proposed code changes ===
All changes are in the <code>dropin-registration</code> topic branches
in the Chnage owner's forks:
* [https://src.fedoraproject.org/fork/mschorm/rpms/unixODBC/c/fddf280ed2a7afdc…
unixODBC] — drop-in infrastructure, file triggers, <code>%ghost</code>
config, migration scriptlets,
[https://src.fedoraproject.org/fork/mschorm/rpms/unixODBC/c/70abcfdeeb41baca…
manual page] for the new script
* [https://src.fedoraproject.org/fork/mschorm/rpms/mariadb-connector-odbc/c/d5…
mariadb-connector-odbc] — ship <code>10-mariadb.ini</code> drop-in
snippet
* [https://src.fedoraproject.org/fork/mschorm/rpms/mysql-connector-odbc/c/0b03…
mysql-connector-odbc] — ship <code>10-mysql.ini</code> drop-in snippet
* [https://src.fedoraproject.org/fork/mschorm/rpms/postgresql-odbc/c/e13692332…
postgresql-odbc] — ship <code>10-postgresql.ini</code> drop-in snippet
* [https://src.fedoraproject.org/fork/mschorm/rpms/freetds/c/d36341635aa8a230a…
freetds] — ship <code>10-freetds.ini</code> drop-in snippet
* [https://src.fedoraproject.org/fork/mschorm/rpms/sqliteodbc/c/316aa92e9326d1…
sqliteodbc] — ship <code>10-sqlite.ini</code> drop-in snippet, remove
legacy <code>odbcinst</code> scriptlets
* [https://src.fedoraproject.org/fork/mschorm/rpms/mdbtools/c/b6f54b24fb8de6f0…
mdbtools] — ship <code>10-mdbtools.ini</code> drop-in snippet
== Detailed Description ==
=== Background ===
The ODBC driver manager (<code>unixODBC</code>) uses
<code>/etc/odbcinst.ini</code> to map driver names to shared
libraries. In Fedora, this file has historically been shipped as
<code>%config(noreplace)</code> inside the <code>unixODBC</code>
package, pre-populated with entries for all known Fedora ODBC drivers.
The driver entries in Fedora were in poor shape.
<code>FileUsage</code> values were wrong for multiple drivers, library
paths were hardcoded and multilib-unfriendly, and the FreeTDS entry
contained a dead <code>Port</code> key that the driver never reads
from <code>odbcinst.ini</code>. These problems persisted because
driver entries lived in the wrong package — fixing a driver's
registration required a change to <code>unixODBC</code>, not to the
driver package itself.
This coupling created several structural problems:
* '''Wrong ownership:''' Driver packages had no control over their own
registration. A driver maintainer who wanted to fix or update their
entry had to coordinate a change in <code>unixODBC</code>.
* '''Stale entries:''' All known drivers were pre-populated in the
config regardless of whether they were installed, leading to broken
references.
* '''Invisible drivers:''' New driver packages (e.g.
<code>mdbtools-odbc</code>) were not registered at all until someone
manually added them to the <code>unixODBC</code> spec.
<code>mdbtools-odbc</code> was invisible to ODBC applications after
install.
* '''Fragile upgrades:''' The <code>%config(noreplace)</code>
semantics mean RPM silently keeps the old file on upgrade, so
corrections (like fixed <code>FileUsage</code> values) never reach
existing installations.
Of all 6 driver packages in Fedora, only <code>sqliteodbc</code>
attempted self-registration via <code>%post</code>/<code>%preun</code>
scriptlets calling <code>odbcinst -i</code>/<code>odbcinst -u</code>.
The other 5 relied entirely on <code>unixODBC</code> pre-populating
their entries.
=== What is changing ===
The modernization consists of two groups of changes:
'''Already in Fedora Rawhide (foundation work):'''
* ODBC driver plugins moved from <code>%{_libdir}</code> to a
dedicated <code>%{_libdir}/odbc/</code> directory across all driver
packages.
* <code>unixODBC</code> compiled with
<code>--with-odbc-driver-path=%{_libdir}/odbc</code>, enabling bare
library names (e.g. <code>Driver = libmaodbc.so</code> instead of full
paths).
* <code>FileUsage</code> values corrected across all drivers
([https://bugzilla.redhat.com/show_bug.cgi?id=2453060 BZ#2453060]).
* <code>Suggests:</code> added for all 6 ODBC driver packages.
* Removal of a 17-year-old dead patch (<code>keep-typedefs.patch</code>).
'''Proposed in this change (driver registration):'''
* Each driver package ships a static <code>.ini</code> snippet file to
<code>/usr/lib/odbc/odbcinst.d/</code> (vendor defaults).
* <code>unixODBC</code> owns <code>%transfiletriggerin</code> and
<code>%transfiletriggerpostun</code> scriptlets that run a
regeneration script (<code>odbcinst-generate</code>) whenever snippets
are installed or removed.
* The regeneration script merges all snippets (vendor defaults
overlaid by admin overrides) and atomically replaces
<code>/etc/odbcinst.ini</code>.
* <code>/etc/odbcinst.ini</code> changes from
<code>%config(noreplace)</code> to <code>%ghost</code> — RPM tracks
ownership but the file is never shipped; it is always generated.
* Administrators can override or disable vendor drivers via
<code>/etc/odbc/odbcinst.d/</code> (see below).
=== Drop-in directory layout ===
/usr/lib/odbc/odbcinst.d/ ← vendor snippets (shipped by driver RPMs)
10-mariadb.ini
10-mysql.ini
10-postgresql.ini
10-freetds.ini
10-sqlite.ini
10-mdbtools.ini
/etc/odbc/odbcinst.d/ ← admin overrides and additions
/etc/odbcinst.ini ← generated output (%ghost)
'''Override semantics:'''
* Files are named <code>NN-name.ini</code>. The numeric prefix
controls merge order.
* Vendor range: 10–49. Admin range: 50–99.
* When two files share the same name after stripping the prefix (e.g.
<code>10-mariadb.ini</code> and <code>60-mariadb.ini</code>), the
higher-numbered one wins.
* To disable a vendor driver, symlink its snippet to <code>/dev/null</code>:
ln -sf /dev/null /etc/odbc/odbcinst.d/10-freetds.ini
* To apply changes after editing drop-in files manually, run:
<code>odbcinst-generate</code>
These semantics follow the established systemd convention used
throughout Fedora.
=== Precedent ===
This is the standard Fedora pattern for generated configuration. At
least 22 packages use the same <code>%transfiletriggerin</code> +
regeneration model, including:
* <code>glibc-common</code> — <code>/etc/ld.so.conf.d/</code> →
<code>ldconfig</code> → <code>/etc/ld.so.cache</code>
* <code>ca-certificates</code> —
<code>/etc/pki/ca-trust/source/</code> → <code>update-ca-trust</code>
→ <code>ca-bundle.crt</code>
* <code>crypto-policies</code> —
<code>/usr/share/crypto-policies/</code> →
<code>update-crypto-policies</code>
* <code>fontconfig</code> — <code>/usr/share/fonts/</code> →
<code>fc-cache</code>
* <code>shared-mime-info</code> — <code>/usr/share/mime/</code> →
<code>update-mime-database</code>
* <code>glib2</code> — <code>/usr/share/glib-2.0/schemas/</code> →
<code>glib-compile-schemas</code>
=== Migration strategy (for FESCo consideration) ===
This is the area where community input is most welcome.
When upgrading from a system where <code>/etc/odbcinst.ini</code> was
<code>%config(noreplace)</code> to the new <code>%ghost</code> model,
RPM does '''not''' automatically create an <code>.rpmsave</code>
backup. Without intervention, any user modifications to
<code>odbcinst.ini</code> would be silently lost.
The proposed migration strategy:
# A <code>%pretrans</code> Lua scriptlet in <code>unixODBC</code>
detects first-time upgrades (the drop-in directory does not yet exist)
and renames <code>/etc/odbcinst.ini</code> to
<code>/etc/odbcinst.ini.rpmsave</code>. On subsequent upgrades
(drop-in directory already exists), the <code>%pretrans</code> is a
no-op.
# <code>%post</code> checks whether
<code>/etc/odbcinst.ini.rpmsave</code> exists. If so, it prints a
notice to stderr explaining that driver registration has moved to
drop-in snippets, pointing users to the <code>.rpmsave</code> file and
explaining how to migrate custom entries. This notice is repeated on
every upgrade as long as the <code>.rpmsave</code> file remains,
serving as a persistent reminder until the user completes the
migration and removes it.
'''What users need to do:'''
* Users who never modified <code>odbcinst.ini</code>: nothing. All
standard drivers are registered automatically via snippets.
* Users who added custom driver entries: copy their custom
<code>[sections]</code> from <code>odbcinst.ini.rpmsave</code> into a
new file under <code>/etc/odbc/odbcinst.d/</code> and run
<code>odbcinst-generate</code>.
'''Alternatives considered:'''
* ''Content-based detection'' (parse the file to detect user
modifications): rejected as unreliable in RPM's limited Lua
environment.
* ''Always preserve'' (never create <code>.rpmsave</code>): rejected
because it leaves the old static file alongside the new generated one,
causing confusion.
* ''In-place migration'' (automatically convert user entries to
drop-in files): rejected as too complex and opaque. Users should be
aware of the new mechanism.
=== Rejected ideas: scriptlet-based registration (Debian/Ubuntu, openSUSE) ===
Other distributions use <code>odbcinst -i</code>/<code>odbcinst
-u</code> commands in driver package scriptlets
(<code>postinst</code>/<code>postrm</code> on Debian,
<code>%post</code>/<code>%preun</code> on openSUSE). I considered and
rejected this for Fedora due to various bugs present in this approach.
'''How it works in Debian/Ubuntu:''' Each driver package calls
<code>odbcinst -i -d -f
/usr/share/<driver>/odbcinst.ini.template</code> in its
<code>postinst</code> and <code>odbcinst -u -d</code> in its
<code>postrm</code>. This approach has generated real bugs over more
than a decade:
* [https://bugs.launchpad.net/ubuntu/+source/freetds/+bug/1173083
Ubuntu Bug #1173083]: <code>tdsodbc</code> used a debconf prompt to
ask whether to register the driver. In automated installs (containers,
CI, preseed), the question was never answered, leaving FreeTDS
silently unregistered. Open for 12 years before being fixed.
* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001141 Debian
Bug #1001141]: <code>odbc-mariadb</code> called <code>odbcinst</code>
in its maintainer scripts but did not declare a dependency on the
<code>odbcinst</code> binary, causing silent registration failures.
'''How it works in openSUSE:''' Similar, using RPM
<code>%post</code>/<code>%preun</code> scriptlets. All errors are
suppressed with <code>> /dev/null 2>&1 || true</code>, so failures are
completely silent. Coverage is inconsistent: only 3 of 5 driver
packages self-register; <code>mariadb-connector-odbc</code> ships a
sample <code>.ini</code> but no scriptlets; <code>mdbtools</code> has
its ODBC driver incorrectly placed in the <code>-devel</code>
subpackage.
'''Why the scriptlet approach is fundamentally fragile:'''
* '''Race conditions:''' <code>odbcinst</code> performs a
read-modify-write cycle on <code>/etc/odbcinst.ini</code> without file
locking. If two driver packages run scriptlets concurrently, the file
can be corrupted or one registration silently lost.
* '''Reference counting:''' <code>odbcinst</code> maintains a
reference count per driver entry. A failed or interrupted scriptlet
can leave the count out of sync, resulting in stale entries that never
get removed or premature removal of valid entries.
* '''Cross-package file modification:''' Multiple independent packages
all modify a file owned by <code>unixODBC</code>, violating single
file ownership.
* '''Per-driver boilerplate:''' Every driver package must
independently implement registration logic, template files, and
correct dependency declarations. Each one is a potential source of
bugs.
'''Why the drop-in approach is better:''' RPM file triggers
(<code>%transfiletriggerin</code>) are transactional — they fire once
after the entire transaction completes, not once per package. The
regeneration script rebuilds <code>/etc/odbcinst.ini</code> from
scratch using only the snippet files currently on disk. There is no
read-modify-write race, no reference counting, no possibility of stale
entries, and driver packages need zero scriptlet logic — they ship a
static file and nothing else.
With this change, Fedora would be the first distribution with a
systemic, race-free, declarative ODBC driver registration mechanism
with first-class admin override semantics.
== Feedback ==
== Benefit to Fedora ==
* '''Decoupled driver registration:''' Each driver package owns its
own registration. Adding a new ODBC driver to Fedora no longer
requires changes to <code>unixODBC</code>.
* '''Correct out-of-the-box experience:''' Only installed drivers
appear in the config. Installing a driver automatically makes it
visible to applications; removing it automatically cleans up. This
fixes the long-standing problem where <code>mdbtools-odbc</code> was
installable but invisible to ODBC applications.
* '''Admin override mechanism:''' System administrators can override
vendor defaults or disable drivers without editing generated files,
using the same drop-in pattern familiar from systemd, ldconfig, and
crypto-policies.
* '''Bare library names:''' Driver entries use plain library names
(e.g. <code>Driver = libmaodbc.so</code>) resolved via a compiled-in
search path, eliminating hardcoded <code>%{_libdir}</code> paths and
multilib ambiguity.
* '''Correct metadata:''' <code>FileUsage</code> values are fixed
across all drivers. Fedora becomes the first distribution to ship
correct values for all its ODBC drivers.
* '''Reduced spec complexity:''' Driver packages no longer need
<code>%post</code>/<code>%preun</code> scriptlets for registration. A
single static <code>.ini</code> file per driver replaces all of it.
== Scope ==
* Proposal owners:
** Implement drop-in infrastructure in <code>unixODBC</code>
(directories, regeneration script, file triggers, <code>%ghost</code>
config, migration scriptlets)
** Add drop-in snippet files to all 6 driver packages:
<code>mariadb-connector-odbc</code>,
<code>mysql-connector-odbc</code>, <code>postgresql-odbc</code>,
<code>freetds</code>, <code>sqliteodbc</code>, <code>mdbtools</code>
** Remove legacy <code>%post</code>/<code>%preun</code>
<code>odbcinst</code> scriptlets from <code>sqliteodbc</code>
** Test upgrade scenarios in containers via COPR
* Other developers:
** No action required from other package maintainers. The change is
self-contained within the 7 packages listed above.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with the Fedora Strategy: Fedora leads in the Linux
distribution development. This change adopts a modern,
well-established Fedora pattern for an area of the stack that has
lagged behind.
== Upgrade/compatibility impact ==
On upgrade from a previous Fedora release:
* <code>/etc/odbcinst.ini</code> is saved as
<code>/etc/odbcinst.ini.rpmsave</code>.
* A new <code>/etc/odbcinst.ini</code> is generated from drop-in snippets.
* All standard drivers (MariaDB, MySQL, PostgreSQL, FreeTDS, SQLite,
MDBTools) are registered automatically if their packages are
installed.
* Users with custom driver entries in the old
<code>odbcinst.ini</code> need to migrate them to drop-in snippet
files under <code>/etc/odbc/odbcinst.d/</code>. A notice is printed
during upgrade with instructions.
Applications using ODBC continue to work without changes. The
generated <code>odbcinst.ini</code> uses the same INI format as
before; only the mechanism that produces it has changed.
== How To Test ==
Test builds are available in COPR:
[https://copr.fedorainfracloud.org/coprs/mschorm/ODBC/ mschorm/ODBC]
'''Fresh install (no previous ODBC config):'''
# Install <code>unixODBC</code> and one or more driver packages
# Verify <code>/etc/odbcinst.ini</code> is generated and contains
entries for the installed drivers
# Verify that uninstalling a driver package removes its entry from
<code>odbcinst.ini</code>
'''Upgrade from current Rawhide (unmodified config):'''
# Start with a system running the current <code>unixODBC</code> (pre-drop-in)
# Upgrade to the new version
# Verify <code>/etc/odbcinst.ini.rpmsave</code> is created
# Verify the new <code>/etc/odbcinst.ini</code> contains correct
entries for installed drivers
'''Upgrade with custom driver entries:'''
# Start with a system where <code>/etc/odbcinst.ini</code> has been
manually edited (e.g. a custom <code>[MyDriver]</code> section added)
# Upgrade to the new version
# Verify <code>/etc/odbcinst.ini.rpmsave</code> preserves the custom entries
# Copy the custom section into <code>/etc/odbc/odbcinst.d/60-mydriver.ini</code>
# Run <code>odbcinst-generate</code>
# Verify the custom driver appears in the regenerated
<code>/etc/odbcinst.ini</code>
'''Admin override:'''
# Install <code>mariadb-connector-odbc</code> (ships
<code>10-mariadb.ini</code>)
# Create <code>/etc/odbc/odbcinst.d/60-mariadb.ini</code> with modified settings
# Run <code>odbcinst-generate</code>
# Verify the admin override takes precedence
'''Driver disable:'''
# <code>ln -sf /dev/null /etc/odbc/odbcinst.d/10-freetds.ini</code>
# Run <code>odbcinst-generate</code>
# Verify FreeTDS no longer appears in <code>/etc/odbcinst.ini</code>
== User Experience ==
For most users, the change is invisible. Installing an ODBC driver
package automatically registers it; removing it automatically
unregisters it. No manual <code>odbcinst</code> commands are needed.
Power users and administrators gain a familiar drop-in override
mechanism. Customizing ODBC driver registration now works the same way
as customizing library paths (<code>ld.so.conf.d</code>) or CA
certificates (<code>ca-trust</code>).
Users upgrading from a previous Fedora release who had custom entries
in <code>odbcinst.ini</code> will see a migration notice on each
upgrade until they complete the migration and remove the
<code>.rpmsave</code> file.
== Dependencies ==
All 7 affected packages are maintained by the change owner:
* <code>unixODBC</code>
* <code>mariadb-connector-odbc</code>
* <code>mysql-connector-odbc</code>
* <code>postgresql-odbc</code>
* <code>freetds</code>
* <code>sqliteodbc</code>
* <code>mdbtools</code>
No other packages are affected. The generated
<code>/etc/odbcinst.ini</code> is format-compatible with the previous
static file.
== Contingency Plan ==
* Contingency mechanism: Revert the <code>unixODBC</code> spec to ship
a static <code>%config(noreplace)</code> <code>odbcinst.ini</code> and
remove drop-in snippet files from driver packages. This is a
straightforward revert of the topic branch in each package.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? '''No'''
== Documentation ==
* [https://bugzilla.redhat.com/show_bug.cgi?id=2453060 BZ#2453060] —
Standardize unixODBC connector installation directory
* [https://copr.fedorainfracloud.org/coprs/mschorm/ODBC/ COPR test
repository: mschorm/ODBC]
* A new <code>odbcinst-generate(1)</code> man page will be shipped
with the <code>unixODBC</code> package, documenting the regeneration
tool, drop-in directory layout, and override semantics
* The existing upstream <code>odbcinst.ini(5)</code> man page will be
updated or supplemented with a note about the drop-in mechanism
== Release Notes ==
The ODBC driver stack has been modernized. ODBC driver registration
now uses a drop-in snippet mechanism: each driver package ships a
small <code>.ini</code> file that is automatically merged into
<code>/etc/odbcinst.ini</code> when the package is installed or
removed. Administrators can override vendor defaults or add custom
drivers by placing files in <code>/etc/odbc/odbcinst.d/</code>.
Users who had custom entries in <code>/etc/odbcinst.ini</code> will
find their previous configuration saved as
<code>/etc/odbcinst.ini.rpmsave</code> after upgrading. Custom driver
sections should be migrated to individual files under
<code>/etc/odbc/odbcinst.d/</code>.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/MySQL_9.7
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-mysql-9-7-self-c…
This is a proposed Change for Fedora Linux.
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 ==
MySQL packages in Fedora use a versioned layout (e.g.
<code>mysql8.4</code>, <code>mysql9.7</code>), where each version
provides versioned sub-packages. One version at a time is designated
the "distribution default" and additionally provides unversioned
package names (e.g. <code>mysql-server</code>,
<code>mysql-devel</code>). This change switches the distribution
default from MySQL 8.4 to MySQL 9.7 in Fedora 45.
== Owner ==
* Name: [[User:mschorm|Michal Schorm]]
* Email: mschorm(a)redhat.com
== Detailed Description ==
A macro in the MySQL SPECfiles controls which version provides the
unversioned names. Flipping this macro in both <code>mysql8.4</code>
and <code>mysql9.7</code> SPECfiles simultaneously switches the
distribution default. Two "distribution default" packages cannot
coexist due to file-level <code>Conflicts</code>, so the change must
be coordinated.
Comparable switches were done for MySQL in Fedora 43 (8.0 → 8.4) and
for MariaDB in Fedora 44 (10.11 → 11.8), both without issues.
== Feedback ==
== Benefit to Fedora ==
MySQL 9.7 is the latest LTS version of MySQL, released on April 21,
2026. It is the first new LTS since MySQL 8.4 (April 2024) and
consolidates two years of innovation releases (9.0 through 9.6).
Fedora's role as a leading-edge distribution makes it the right place
to ship the latest MySQL LTS.
== Scope ==
* Proposal owners:
** Switch the macro in both <code>mysql8.4</code> and
<code>mysql9.7</code> SPECfiles
** Audit all packages that depend on <code>mysql-devel</code>,
<code>mysql-libs</code>, or <code>mysql-server</code> and verify they
build and work correctly against MySQL 9.7
** File bugs and/or PRs for any packages that need fixes
* Other developers:
** Cooperate on fixes if their package needs adjustment for MySQL 9.7
compatibility
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with the Fedora Strategy: Fedora leads in the Linux
distribution development
== Upgrade/compatibility impact ==
Users upgrading from Fedora 44 (which has MySQL 8.4 as default) to
Fedora 45 will have their MySQL installation upgraded to 9.7.
Database administrators should follow the standard MySQL major version
upgrade procedure:
# Back up all databases before upgrading
# Run <code>dnf update</code>
# MySQL 9.7 runs <code>mysql_upgrade</code> automatically on first start
MySQL 8.4 remains available in Fedora 45 as
<code>mysql8.4-server</code> for users who need more time to migrate.
'''Note:''' Upgrading directly from MySQL 8.4 to 9.7 is the supported
LTS-to-LTS upgrade path. Skipping LTS versions (e.g. 8.4 directly to a
future 10.x) is not supported by upstream.
'''Note:''' The <code>mysql_native_password</code> authentication
plugin was removed in the MySQL 9.x series. Applications still relying
on it must switch to <code>caching_sha2_password</code>.
'''Note:''' The <code>replica_parallel_type</code> system variable has
been removed. Replication setups using it must be updated before
upgrading.
'''Note:''' MySQL 9.7, like 8.4, does not support 32-bit builds. This
was already handled in Fedora 43.
== How To Test ==
'''Fresh install:'''
* <code>dnf install mysql-server</code> → installs <code>mysql9.7-server</code>
* <code>dnf install mysql8.4-server</code> → installs
<code>mysql8.4-server</code>
* <code>dnf install mysql9.7-server</code> → installs
<code>mysql9.7-server</code>
* Verify the server starts, accepts connections, and runs basic queries
'''Upgrade scenario:'''
* Running <code>dnf update</code> from a Fedora 44 installation with
MySQL 8.4 results in <code>mysql9.7-server</code>
* Verify data integrity after the automatic upgrade
'''Staying on 8.4 (manual steps):'''
# Disable the service: <code>systemctl disable --now mysqld</code>
# Run <code>dnf update</code> (installs 9.7)
# Swap back: <code>dnf swap mysql-server mysql8.4-server --allowerasing</code>
# Restore service: <code>systemctl enable --now mysqld</code>
'''Conflict test:'''
* Installing both <code>mysql8.4-server</code> and
<code>mysql9.7-server</code> must fail gracefully with a conflict
message about <code>mysql-server-any</code>
== User Experience ==
Users get access to MySQL 9.7's features and enhancements. The
installation and management experience remains identical.
== Dependencies ==
Packages that need rebuild (BuildRequire <code>mysql-devel</code> /
link against <code>libmysqlclient</code>):
* <code>mysql-connector-odbc</code> -
[https://src.fedoraproject.org/rpms/mysql-connector-odbc/blob/rawhide/f/mysq…
BuildRequires: mysql-devel]
* <code>mysql-connector-python</code> -
[https://src.fedoraproject.org/rpms/mysql-connector-python/blob/rawhide/f/my…
BuildRequires: mysql-devel]
* <code>perl-DBD-MySQL</code> -
[https://src.fedoraproject.org/rpms/perl-DBD-MySQL/blob/rawhide/f/perl-DBD-M…
BuildRequires: mysql-devel]
No RPMFusion packages depend on <code>mysql-devel</code> or
<code>mysql-libs</code>.
== Contingency Plan ==
* Contingency mechanism: revert the macro change in both SPECfiles to
restore MySQL 8.4 as the default
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? '''No'''
== Documentation ==
* MySQL 9.7 Changes & improvements:
https://dev.mysql.com/doc/refman/9.7/en/mysql-nutshell.html
* MySQL 9.7 Release Notes: https://dev.mysql.com/doc/relnotes/mysql/9.7/en/
* MySQL 9.7 Reference Manual: https://dev.mysql.com/doc/refman/9.7/en/
== Release Notes ==
MySQL 9.7 is the latest long-term support release. It consolidates all
features from the innovation releases 9.0 through 9.6 on top of the
previous LTS (8.4).
Major changes since MySQL 8.4:
https://dev.mysql.com/doc/refman/9.7/en/mysql-nutshell.html
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney