Somehow I missed the orphaning of perl-Parse-EDID.
Anyway, I'd like to take over maintenance of this package as other packages I maintain are dependent on it.
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
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 ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The new DNF5 will provide a significant improvement in user
experiences and performance. The replacement is the second step in
upgrade of Fedora Software Management stack. Without the change there
will be multiple software management tool (DNF5, old Microdnf,
PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
providing a different behavior, and not sharing a history. We can also
expect that DNF will have only limited support from upstream. The DNF5
development was announced on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Fedora-Devel] list in 2020.
=== New DNF5 Features ===
* Fully featured package manager without requirement of Python
** Smaller system
** Faster
** Replace DNF and Microdnf
* Unified behavior of in the software management stack
** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
*** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently in comparison to DNF
** Shared configurations
*** In DNF4 not all configuration is honored by PackageKit and Microdnf
** DNF/YUM was developed for decades with impact of multiple styles
and naming conventions (options, configuration, options, commands)
* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into Desktop
** Support of Modularity and Comps group
* Performance improvement
** Loading of repositories
** Advisory operations
** RPM queries
*** Name filters with a case-insensitive search (the `repoquery` command)
** Smart sharing of metadata between dnf5 and daemon
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39
* Decrease of a maintenance cost in the long term
** Shared plugins
** Removal of functional duplicates
* Fully integrated Modularity in LIBDNF5 workflows
** The Modularity is supported in DNF and LIBDNF but it is not fully
integrated. Integration was not possible due to limitation of
compatibility with other tools (PackageKit)
** Fully integrated Modularity required changes in the library workflow
=== Major codebase improvements ===
*Reports in structure
** DNF reports a lot of important information only in logs
* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future
* Unify Python bindings
** Formal Libdnf provides two types of Python bindings
*** CPython (hawkey)
*** SWIG (libdnf)
** Maintaining and communication between both bindings requires a lot
of resources
** Binding unification was not possible without breaking API compatibility
* SWIG bindings
** With SWIG we can generate additional bindings without spending huge resources
** Code in particular languages will be very similar to each other
* Separation of system state from history DB and `/etc/dnf/module.d`
** In dnf-4 the list of userinstalled packages and list of installed
groups along with the lists of packages installed from them is
computed as an aggregation of transaction history. In dnf5 it will be
stored separately, having multiple benefits, among them that the
history database will serve for informational purposes only and will
not define the state of the system (it gets corrupted occasionally
etc.).
** Data stored in `/etc/dnf/module.d` were not supposed to be user
modifiable and their format is not sufficient (missing information
about installed packages with installed profiles)
*** Content of `/etc/dnf/module.d` will be moved into the System State
== Feedback ==
== Benefit to Fedora ==
== Scope ==
* Proposal owners:
DNF5 is still in the development and some of the features or options
are not yet available. We still have to finish the implementation of
Modularity, storing internal data related to History and System State,
and also documentation and man pages. DNF5 can be tested from
repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's github repository is here -
https://github.com/rpm-software-management/dnf5/
* Other developers:
* Release engineering: [https://pagure.io/releng/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 Objectives:
== Upgrade/compatibility impact ==
The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`,
`python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`.
=== Compatibility ===
The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users
will see the replacement as an upgrade of DNF with limited but
documented syntax changes. The DNF5 will provide some compatible
aliases of commands and options to improve adoption of the DNF5.
== How To Test ==
Install `dnf5` package from
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
== User Experience ==
* Improved progress bars
* Improved transaction table
* Transaction progress reports including scriptlets reports
* Support of local rpm for transaction operation
* Great bash completion (better then DNF has)
* New commands and options that are only available with `DNF`
== Dependencies ==
There is a long list of dependent packages
=== dnf ===
auter
calamares
copr-builder
cpanspec
dnf-plugin-diff
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
policycoreutils-devel
rbm
subscription-manager
supermin
system-config-language
=== python3-dnf ===
anaconda-core
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
pungi
python3-bodhi-client
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-imgcreate
python3-libreport
retrace-server
system-config-language
=== libdnf ===
PackageKit
copr-builder
gnome-software-rpm-ostree
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd
=== python3-hawkey ===
mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline:
* Blocks release?
== Documentation ==
none
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://bugzilla.redhat.com/show_bug.cgi?id=2124697
I'm willing to swap this one with a package of similar complexity.
This package / review bug has been extensively reviewed -- 87 comments(!!)
on the review already. We are pretty sure it is in good shape now.
As it is a "C library" that is actually written in Rust it's a bit
unusual because it has to obey the Rust / Cargo guidelines.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
https://pagure.io/fesco/issue/2870https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
This change proposal has been under discussion and revision for a while. A
lot of work has gone in to this plan to minimize the disruption. Still, dnf
is a core piece of software and we want to make sure everyone understands the
proposal and has an opportunity to discuss it.
The final revision of the proposal is available at the URL above. FESCo is
waiting one more week for any remaining discussion on the change proposal. We
plan to bring the proposal up for vote in the next meeting.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
Hi,
I'm orphaning the package python3-script. It hasn't received an update in years, nobody depends on it and I don't think anyone is using it.
Feel free to take it if it's useful for you.
Kind regards.
All dependent packages have successfully rebuilt in COPR and will be
completed in a side tag.
The following dependencies will be rebuilt:
OpenImageIO
usd
blender
krita
luxcorerender
Thanks,
Richard
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 18:00UTC in #fedora-meeting on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2023-01-10 17:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922
APPROVED (+5, 0, -0)
Change: Pyramid 2.0
https://pagure.io/fesco/issue/2924
APPROVED (+6, 0, -0)
Change: Xfce 4.18
https://pagure.io/fesco/issue/2925
APPROVED (+6, 0, -0)
Change: Unified Kernel Support Phase 1
https://pagure.io/fesco/issue/2926
APPROVED (+5, 0, -0)
Change: X Server Prohibits Byte-swapped Clients
https://pagure.io/fesco/issue/2927
APPROVED (+6, 0, -0)
= Followups =
#2870 Change proposal: Replace DNF with DNF5
https://pagure.io/fesco/issue/2870
= New business =
None at this time.
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.