F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
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: jmra...@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/de...@lists.fedoraproject.org/thread/NWSURJRGZAIIMNZJT244DHDPOG2PBQXZ/ 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
F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/NodejsRepackaging 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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages. == Owner == * Name: [[User:SGallagh| Stephen Gallagher]] * Email: sgall...@redhat.com == Detailed Description == We will be creating the packages nodejs-16, nodejs-18 and (in April) nodejs-20. These packages will be parallel-installable (with the exception of the -devel subpackages) and provide `/usr/bin/node-$MAJOR`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version. Notes: * The default in Fedora 38 will be Node.js 18. If a user was to install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node` * The policy going forward will be to have the most recently-released version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime. == Feedback == [https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/ Mailing list thread] Neal Gompa raised the question of using a subpackage to own `/usr/bin/node` instead of using the `alternatives` subsystem, citing python as an example. My response was that the problem with this is that I want `/usr/bin/node` to always be available so long as any `nodejs-$MAJOR` version is installed. It also ensures that the `node(1)` manpage always matches the `/usr/bin/node` executable. == Benefit to Fedora == === User Benefits === * Provides a simple way to have a different (or multiple) Node.js interpreters on their system. No dealing with Modularity. * Enables multiple versions of Node.js on the system (can test code against different versions without using containers) === Packager Benefits === * No more modules to maintain. * Availability of multiple Node.js versions in the buildroot means that other `nodejs-*` packages can test against multiple supported options. == Scope == * Proposal owners: The packaging work is done and can be played with at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ today. * Other developers: There should be no need to change any dependent packages, though packagers of Node.js software may wish to take advantage of the testing opportunities afforded. * Release engineering: * Policies and guidelines: We will be updating the Node.js Packaging Guidelines with the new best practices. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Systems using the existing nodejs RPM package will be upgraded to the matching `nodejs-$MAJOR` version. Work is pending on how to migrate users of Modular Node.js to the new packages. == How To Test == == User Experience == Done correctly, this should be handled entirely without the user's need to know about it. == Dependencies == == 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 == https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/ == Release Notes == Multiple releases of Node.js may now be installed in parallel from the Fedora repositories. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-09-05.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change abduco dfateyev, orphan0 weeks ago bumpversionjdornak, orphan 0 weeks ago clinfo orphan 0 weeks ago colm jtaylor, lorbus, orphan 0 weeks ago ellorphan 0 weeks ago espresso-abavigne, orphan 0 weeks ago fortune-modepel-packagers-sig, orphan, 0 weeks ago sergiomb, shlomif geteltoritoorphan 0 weeks ago gimp-focusblur-plugin orphan 0 weeks ago git-archive-allorphan 0 weeks ago git-fame fale, ignatenkobrain, orphan0 weeks ago git-lab-porcelain orphan 3 weeks ago gmqcc orphan 0 weeks ago hctavigne, orphan 0 weeks ago httrackcicku, fale, orphan 0 weeks ago ipsilonorphan, puiterwijk, simo2 weeks ago kelbt orphan 0 weeks ago libmaxminddb jtaylor, mruprich, orphan 0 weeks ago libtomlorphan 0 weeks ago libtvdborphan 1 weeks ago mcpanelorphan 0 weeks ago metapixel orphan 1 weeks ago mirrorlist-server adrian, orphan, rust-sig0 weeks ago monobristolorphan 0 weeks ago mozilla-https-everywhere orphan, rathann 1 weeks ago novacom-client orphan 2 weeks ago novacom-server orphan 2 weeks ago nsca-ngorphan 0 weeks ago origin go-sig, orphan, tdawson 0 weeks ago parzip orphan 0 weeks ago perl-BSSolvngompa, orphan 0 weeks ago perl-Parse-Debian-Packages orphan 0 weeks ago php-psr-http-clientorphan 0 weeks ago pidgin-save-conv-order orphan 1 weeks ago python-aiofilesorphan 0 weeks ago python-aioodbc orphan 0 weeks ago python-aiorpcx jonny, orphan 0 weeks ago python-argopt orphan 0 weeks ago python-arpybochecha, orphan, python-sig0 weeks ago python-august orphan 2 weeks ago python-bitstruct orphan 2 weeks ago python-calligrabot merlinm, orphan 2 weeks ago python-colanderinfra-sig, lmacken, orphan, ralph 0 weeks ago python-coreapi orphan 0 weeks ago python-coreschema orphan 0 weeks ago python-cu2qu orphan 2 weeks ago python-daemonize orphan 0 weeks ago python-devtoolsorphan
