F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
== Summary ==
Currently, the RPM databases is located in `/var`. Let's move it to
`/usr`. The move is already under way in rpm-ostree-based
installations, and in (open)SUSE.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel
Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Email: bugzilla(a)colorremedies.com, michel(a)michel-slm.name, ngompa13(a)gmail.com
== Detailed Description ==
=== Current location ===
<pre>/var/lib/rpm</pre>
=== New location ===
<pre>/usr/lib/sysimage/rpm</pre>
<code>/var/lib/rpm</code> will be a symlink pointing to
<code>/usr/lib/sysimage/rpm</code>
Changing the file system layout to accommodate a snapshot+rollback
regime is implied, but not required by this proposal. For example,
Fedora has long placed `/home` on a separate subvolume (or file
system) so it can be isolated from system root. Likewise, it makes
sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so
these locations continue to carry forward in time, even if the system
root does a rollback.
== Feedback ==
There will be no change to DNF as part of this change proposal. DNF's
history will remain in `/var` until DNF 5. Discussion continues about
the effect of a snapshot+rollback regime on DNF history.
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html
Relocate DNF history to /usr.]
Upstream RPM accept the change, but institutionally don't like the
loss or weakening of a
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
very well known location] for the database, and
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
anticipate complaints].
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing
the databases in `/usr` will more easily facilitate OS rollback,
without affecting `/var`.
* Helps align Fedora variants with each other
** rpm-ostree based systems (including CoreOS, IoT, Silverblue,
Kinoite) already use `/usr/lib/sysimage` for rpmdb.
* Consistency with another RPM-based distro, (open)SUSE has made this change
* Accounts for various snapshot+rollback regimes, i.e. it's a
beneficial change whether Btrfs or device-mapper based regimes.
== Scope ==
* Proposal owners:
** changes in rpm package
*** create the new path
*** create a symlink for the old path pointing to new path
* Other developers:
** changes in SElinux policy
* Release engineering: [https://pagure.io/releng/issue/10441 #Releng
issue 10441]
* 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 ==
Change will be applied to offline upgrades, similar to the RPM sqlite
database change. A systemd service will move the rpmdb from /var to
/usr, then create a symlink pointing to /usr from /var.
# Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst)
# Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in
`/var/lib/rpm/` (rpm package will do this at preinst)
# Change the dbpath in `/usr/lib/rpm/macros` to
`/usr/lib/sysimage/rpm` (rpm package will be patched to do this on
F36+)
# Request rpm rebuild the database (done via systemd service)
# Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` ->
`/usr/lib/sysimage/rpm` (done via systemd service)
== How To Test ==
# Perform a new clean install, or upgrade a system
# Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm`
# Check that `/usr/lib/sysimage/rpm` is populated with at least
`rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and
`rpmdb.sqlite-wal`
# Confirm `rpm -q <package>` and/or `rpm -qa` still work
== User Experience ==
* symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm`
Otherwise, the change should be invisible to users.
== Dependencies ==
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to
`/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it
does and whether it should be changed or add the additional path
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 months
upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
4 months
Heads-up: trousers (TPM 1.2) silently orphaned
by Michel Alexandre Salim
Hi all,
`trousers` got silently orphaned around the time an EPEL9 branch for it
was requested: https://bugzilla.redhat.com/show_bug.cgi?id=2032258
Looks like we're slowly uncoupling ourselves from it, e.g.
- for ARM, uboot-tools no longer pulls in vboot-utils which pulls in
trousers: https://lists.fedoraproject.org/archives/list/scm-commits@lists.fedorapro...
- Neal disabled TPM/TSS 1.2 support in strongswan, dropping the trousers
dependency, in https://src.fedoraproject.org/rpms/strongswan/pull-request/13
but there are several dependencies still around (strongswan still shows
up here as the PR just got merged a few hours ago)
```
~
❯ sudo dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --whatrequires trousers-devel
Last metadata expiration check: 0:00:10 ago on Thu 16 Dec 2021 10:08:04 AM PST.
ecryptfs-utils-0:111-25.fc36.src
gnutls-0:3.7.2-2.fc35.src
golang-github-google-tspi-0:0.2.0-6.fc35.src
openconnect-0:8.10-7.fc35.src
strongswan-0:5.9.4-3.fc36.src
tpm-quote-tools-0:1.0.4-8.fc35.src
tpm-tools-0:1.3.9-12.fc36.src
vboot-utils-0:20190823-8.git595108c0.fc36.src
```
Do we want to keep trousers in Fedora? If so someone who needs it should probably step up, if not, we should toggle it off in these packages. Maintainers BCC:ed.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
4 months, 1 week
Self Introduction: Jan Baudisch
by Jan Baudisch
Hi,
I am a computer science student from Germany and have used Fedora for
at least 2 years by now.
Using COPR I gained some experience in buidling packages but recently I
wanted to try building packages conforming to the guidelines and
getting them into Fedora. My interest is mostly in Rust and that is why
I would like to contribute Rust packages. I already got started here:
https://copr.fedorainfracloud.org/coprs/janbaudisch/rust/packages
For now my main interest would be to get the Rocket framework packaged,
as many projects rely on it and on the way I discovered some key Rust
crates not packaged yet.
I feel like some of them are ready for submission and will file the
first review requests soon.
Looking forward to working on this!
Jan
4 months, 1 week
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email: <tagoh(a)redhat.com>
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
<pre>
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272</pre>
<pre>
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
</pre>
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* 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 ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your
language>` and `fc-match monospace:lang=<your language>`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for most languages will be Google Noto fonts instead
of DejaVu, to keep consistency on the text rendering and to provide
better quality among languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 months, 1 week
Rust Stack Spring Cleaning (in Winter)
by Fabio Valentini
Hello Rust packagers,
(I'm sending this email to the devel and rust lists, and I've added all directly
affected package maintainers in Bcc - because adding them all to the "To" or
"CC" fields would make the lists reject this message, I believe.)
I have been working on and preparing some more clean-ups in the Rust stack, and
I came across a large-ish number of Rust packages that were imported to Fedora,
but the recommended "initial setup" for them was never finished.
I have started by adding them all "rust-*" packages to koschei, which makes it
way easier for me to see at a glance whether there are any broken packages in
our Rust stack at any point in time.
I will also make sure all those packages are correctly set up with anitya /
release-monitoring.org, so that we actually get notifications for new versions
of all those crate packages.
Additionally, I would ask of all of you to make sure all your packages have been
added to the @rust-sig group on src.fedoraproject.org (at least with "commit"
access). Without that, it makes it very hard for us to keep the Rust stack
up-to-date and in working order, because the "rust-sig" list / bugzilla account
does not get CC'd on new bugs that way, and your bugs do not show up in our
BugZilla queries.
For example, I have been working on packaging and updating the RustCrypto
stack of crates, and found that most of the already existing
(security-sensitive!) crates are not "completely" set up, and are now out of
date, just because I didn't even know about those packages (and some were also
not set up with release-monitoring.org).
In the interest of keeping the Rust stack in Fedora in a good state, please
add "@rust-sig" group to all you Rust packages on src.fedoraproject.org, unless
there is a very good reason not to do so (and if that is the case for a
particular package in this list, I'd be interested in knowing the reason, as
well).
If you want a scripted way of adding "@rust-sig" group to many packages, you
can generate an API token on src.fedoraproject.org (with "Modify an existing
project") access level, and use the simple Python script from this GitHub gist:
https://gist.github.com/decathorpe/9d128982cb00e2d345d9e397372538ec
Below is the list of "incompletely set-up" packages, in alphabetic order, and
at the bottom, there is a list of packages per affected package maintainer.
Thanks,
Fabio
===
- rust-arrayvec0.5: eclipseo
- rust-asn1: cheimes
- rust-asn1_derive: cheimes
- rust-assert-impl: dcavalca
- rust-aws-nitro-enclaves-cose: pbrobinson
- rust-benfred-read-process-memory: dcavalca
- rust-biscuit: orphan
- rust-bitfield: ignatenkobrain
- rust-block-cipher: ignatenkobrain
- rust-blsctl: javierm
- rust-btrd: dcavalca
- rust-bytelines: ignatenkobrain
- rust-clap_generate: eclipseo
- rust-clap_generate_fig: eclipseo
- rust-clircle: eclipseo
- rust-combine: dcavalca
- rust-console0.13: ignatenkobrain
- rust-cryptoki: pbrobinson
- rust-cryptoki-sys: pbrobinson
- rust-cty: nickblack
- rust-dbus-codegen: pbrobinson
- rust-dbus-crossroads: pbrobinson
- rust-derivative: pbrobinson
- rust-directories-next: jbtrystram
- rust-dirs2: ignatenkobrain
- rust-elf: dcavalca
- rust-enumflags2: ignatenkobrain, pbrobinson
- rust-env_proxy: dcavalca
- rust-epoll: slp
- rust-event-listener: dcavalca
- rust-fasteval: zbyszek
- rust-hostname-validator: ignatenkobrain
- rust-inferno: dcavalca
- rust-itertools0.9: ignatenkobrain
- rust-josekit: pbrobinson
- rust-js-sys: pbrobinson
- rust-keccak: pbrobinson
- rust-log-panics: salimma
- rust-mbox: ignatenkobrain, pbrobinson
- rust-navi: jbtrystram
- rust-netlink-packet-core: cathay4t, ffmancera
- rust-netlink-packet-route: cathay4t, ffmancera
- rust-netlink-packet-utils: cathay4t, ffmancera
- rust-netlink-proto: cathay4t, ffmancera
- rust-netlink-sys: cathay4t, ffmancera
- rust-num-format: dcavalca
- rust-oauth2: ctron, jbtrystram
- rust-oid: pbrobinson
- rust-openat-ext: walters
- rust-pam-sys: eneville
- rust-parsec-client: pbrobinson
- rust-parsec-interface: pbrobinson
- rust-picky-asn1: pbrobinson
- rust-picky-asn1-der: pbrobinson
- rust-picky-asn1-x509: pbrobinson
- rust-psa-crypto: pbrobinson
- rust-pkcs11: pbrobinson
- rust-pleaser: eneville
- rust-process_control: atim, petersen
- rust-proc-maps: dcavalca
- rust-prost: pbrobinson
- rust-prost-build: pbrobinson
- rust-prost-derive: pbrobinson
- rust-prost-types: pbrobinson
- rust-psa-crypto-sys: pbrobinson
- rust-qstring: ctron, jbtrystram
- rust-rand0.7: ignatenkobrain
- rust-rand_chacha0.2: ignatenkobrain
- rust-rand_core0.5: ignatenkobrain
- rust-rand_pcg0.2: ignatenkobrain
- rust-rbspy-ruby-structs: dcavalca
- rust-rbspy-testdata: dcavalca
- rust-read-process-memory: dcavalca
- rust-remoteprocess: dcavalca
- rust-rsa: pbrobinson
- rust-rtnetlink: cathay4t, ffmancera
- rust-sd-notify: pbrobinson
- rust-secrecy: pbrobinson
- rust-serde_with: pbrobinson
- rust-sha3: pbrobinson
- rust-shadow-rs: atim
- rust-shellwords: jbtrystram
- rust-signal-hook-mio: dcavalca
- rust-signature: orphan
- rust-simple_asn1: pbrobinson
- rust-stratisd_proc_macros: jbaublitz
- rust-str_stack: dcavalca
- rust-subprocess: dcavalca
- rust-syslog: eneville
- rust-tabular: jbtrystram
- rust-textwrap0.11: ignatenkobrain
- rust-textwrap0.12: ignatenkobrain
- rust-thread-tree: dcavalca
- rust-toml_edit: dcavalca
- rust-tss-esapi-sys: pbrobinson
- rust-universal-hash: pbrobinson
- rust-version: pbrobinson
- rust-versions: atim
- rust-version-sync0.8: ignatenkobrain
- rust-virtio-bindings: slp
- rust-vm-memory: slp
- rust-vmm-sys-util: slp
- rust-vte_generate_state_changes: ignatenkobrain
- rust-webbrowser: ctron, jbtrystram
- rust-zmq: ueno
Lists by maintainer:
- atim (3): rust-process_control, rust-shadow-rs, rust-versions
- cathay4t (6): rust-netlink-packet-core, rust-netlink-packet-route,
rust-netlink-packet-utils, rust-netlink-proto, rust-netlink-sys,
rust-rtnetlink
- cheimes (2): rust-asn1, rust-asn1_derive
- ctron (3): rust-oauth2, rust-qstring, rust-webbrowser
- dcavalca (19): rust-assert-impl, rust-benfred-read-process-memory,
rust-btrd, rust-combine, rust-elf, rust-env_proxy,
rust-event-listener, rust-inferno, rust-num-format, rust-proc-maps,
rust-rbspy-ruby-structs, rust-rbspy-testdata,
rust-read-process-memory, rust-remoteprocess, rust-signal-hook-mio,
rust-str_stack, rust-subprocess, rust-thread-tree, rust-toml_edit
- eclipseo (4): rust-arrayvec0.5, rust-clap_generate,
rust-clap_generate_fig, rust-clircle
- eneville (3): rust-pam-sys, rust-pleaser, rust-syslog
- ffmancera (6): rust-netlink-packet-core, rust-netlink-packet-route,
rust-netlink-packet-utils, rust-netlink-proto, rust-netlink-sys,
rust-rtnetlink
- ignatenkobrain (17): rust-bitfield, rust-block-cipher,
rust-bytelines, rust-console0.13, rust-dirs2, rust-enumflags2,
rust-hostname-validator, rust-itertools0.9, rust-mbox, rust-rand0.7,
rust-rand_chacha0.2, rust-rand_core0.5, rust-rand_pcg0.2,
rust-textwrap0.11, rust-textwrap0.12, rust-version-sync0.8,
rust-vte_generate_state_changes
- javierm (1): rust-blsctl
- jbaublitz (1): rust-stratisd_proc_macros
- jbtrystram (7): rust-directories-next, rust-navi, rust-oauth2,
rust-qstring, rust-shellwords, rust-tabular, rust-webbrowser
- nickblack (1): rust-cty
- orphan (2): rust-biscuit, rust-signature
- pbrobinson (33): rust-aws-nitro-enclaves-cose, rust-cryptoki,
rust-cryptoki-sys, rust-dbus-codegen, rust-dbus-crossroads,
rust-derivative, rust-enumflags2, rust-josekit, rust-js-sys,
rust-keccak, rust-mbox, rust-oid, rust-parsec-client,
rust-parsec-interface, rust-picky-asn1, rust-picky-asn1-der,
rust-picky-asn1-x509, rust-psa-crypto, rust-pkcs11, rust-prost,
rust-prost-build, rust-prost-derive, rust-prost-types,
rust-psa-crypto-sys, rust-rsa, rust-sd-notify, rust-secrecy,
rust-serde_with, rust-sha3, rust-simple_asn1, rust-tss-esapi-sys,
rust-universal-hash, rust-version
- petersen (1): rust-process_control
- salimma (1): rust-log-panics
- slp (4): rust-epoll, rust-virtio-bindings, rust-vm-memory, rust-vmm-sys-util
- ueno (1): rust-zmq
- walters (1): rust-openat-ext
- zbyszek (1): rust-fasteval
4 months, 1 week
How do we announce new packages?
by Eduard Lucena
Hello people.
First of all, I'm not a developer or a packager, I just try to help with
the little things I know to do. One thing I try to do is to check news,
forums, ML and places where people talk about Fedora.
A thing I noted is that a lot of people in magazines and news sites like
phoronix, hacker news and other sites follow this list to get news about
the project and it started to worry me that a big part of the traffic
follow orphaned and retired packages, but nothing is never
revealed/published when a new package enter the repositories or nothing
similar, maybe a review swap but it's not enough.
Trying to market the number of packages, the amount of free and open source
software that we offer, how this could be measured and published? Is that
something that require to much work?
Br,
--
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
4 months, 2 weeks
F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PostgreSQL_14
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 13 to version 14 in the non-modular (main) builds.
== Owner ==
* Name: [[User:fjanus| Filip Januš]]
* Email: fjanus(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 13 to version 14 in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
=== Plan ===
* Prepare PostgreSQL 14 in Copr (By 2022-01-15)
* Rebuild important dependencies in Copr (By 2022-01-15)
* Debug and fix compatibility issues found in dependencies (a
reasonable amount of non-critical in FTBFS state might be tolerable)
* Prepare Pull requests in Rawhide
* Merge and build PR into Rawhide
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The latest stable software is used by Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 14
**Prepare PostgreSQL 13 as a module for Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 14 (postgresql and libpq) to Rawhide
**Rebuild depended on packages against PostgreSQL 14
**Gather user input on the changes between PostgreSQL 13 and PostgreSQL 14
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any issues with compatibility, but rebuild of the
depended components is recommanded.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 14.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 14 server packages.
If users want to stick with PostgreSQL 13 for a little longer, there
will be PostgreSQL 13 module
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In case
of Postgresql-server, rebuild should be done to make sure all
potential binary incompatibilities are handled.
* PostgreSQL server dependecies
** perl-DBD-Pg
** pgaudit
** qt
** qt3
** qt5-qtbase
** postgres-decoderbufs
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
** pg_repack
== Contingency Plan ==
Revert changes in the non-modular packages and provide PostgreSQL 14
as a module stream only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/14/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 14 release:
https://www.postgresql.org/docs/14/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/14/release-14.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 months, 2 weeks
