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.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
Looks like there are still blockers (like that modular filtering is not implemented yet) - should we wait with voting on "make it the new default" until at least the biggest blockers are resolved?
I'd rather approve this for F39 now, with a set of blockers that would mean we trigger the contingency plan.
It would also be super cool if we ship dnf5 in time for Fedora 38 as an opt-in package in the official repo with official support so we can advertise this one release sooner. The current state of dnf5 is unfortunately not presentable as it seems. I am a bit afraid about doing a leap to it without prior heavy testing at least by our contributors.
Agreed on approving this for F39 now. This change needs a lot of runway and likely stages. Better to approve it now and have plenty of time.
+1
I have great hopes for DNF5 and I think it all looks very promising. But I don't think we should "sign off" on a replacement of the default implementation at this point, at least not without much more information. As minimum, the list of dependant packages and various features (dnf-automatic, history, modular filtering, history, graphical interfaces, python interface, etc.) would need to be drawn up, with a clear categorization of what is blocking for the switch, what is "nice to have", and what is not planned. And I think it's the Change Owner who should create such a list, with input from the community, because they have the best understanding of what is needed and what is possible. The list of topics should also include some provision for bugs reported by early users. For example, would perceived regressions in the output be something that'd block the transition? Then, as F39 nears, we can decide if we're close enough to do the switch or if we should wait.
I more or less agree with @zbyszek. My point of view was that we can agree on the plan now, but we need a clear todo-list of what is needed and we don't make the switch if the todo-list is not finished. Not approving at all and working towards the goal works as well.
Either way, I am -1 for now to avoid automatic approval for the proposal AS IS. This does not mean I am against the goal.
Metadata Update from @churchyard: - Issue tagged with: meeting
I think in order to approve this for f39, we at the very least need to have all the dependencies that we actually use to create and install Fedora ported before we use them to create f39. (ie, mock, koji, oz/imagefactory, osbuild, releng scripts, pungi, anaconda, lorax, releng/scripts, etc)
And ansible :). Besides the fact that @kevin and I maintain it, ansible is heavily used by Fedora Infra, and it requires python3-dnf for the package/dnf module. Without a functioning package module, it's pretty useless.
package
dnf
The proposal is posted in huge advance to the deadline (beta F39). The approval is supposed to help other teams with planning. Without approval it increases the change that the transition will not have enough attention from other teams. Anyway DNF team is willing to help wit transition. Also we can prioritize delivery of missing parts that blocks transition but we need to know what is not working, missing and so on.
This will be discussed during FESCo meeting today at 17:00 UTC. @jmracek (and anyone else interested) are invited!
I re-read the proposal again, and my conclusion is the same as before: the "Scope" section needs a lot more details.
Sorry, but we've had many tough transitions in Fedora, and one of the things that have been learned is that we need to figure out all the stakeholders (human and programmatic) and plan for each one: fix, drop, replace, or ignore. This makes it easier to avoid surprises and much easier to coordinate work. Once we have a list, we should open bugs against various components and have at least a general idea who will do the work.
Some things to add to Scope: - ansible - releng tools that use python3-dnf - releng tools that call dnf repoquery - packaging of DNF5 for Fedora. (Can we please do that as soon as possible, possibly with a separate dnf5-unversion-command subpackage so that people can opt-in for testing?)
ansible
python3-dnf
dnf repoquery
Who is responsible for integration in PackageKit and dnfdaemon and other graphical interfaces? Do we plan to make them wrappers around Dnf5Daemon? What about pungi/anaconda?
I re-read the proposal again, and my conclusion is the same as before: the "Scope" section needs a lot more details. Sorry, but we've had many tough transitions in Fedora, and one of the things that have been learned is that we need to figure out all the stakeholders (human and programmatic) and plan for each one: fix, drop, replace, or ignore. This makes it easier to avoid surprises and much easier to coordinate work. Once we have a list, we should open bugs against various components and have at least a general idea who will do the work. Some things to add to Scope: - ansible - releng tools that use python3-dnf - releng tools that call dnf repoquery - packaging of DNF5 for Fedora. (Can we please do that as soon as possible, possibly with a separate dnf5-unversion-command subpackage so that people can opt-in for testing?) Who is responsible for integration in PackageKit and dnfdaemon and other graphical interfaces? Do we plan to make them wrappers around Dnf5Daemon? What about pungi/anaconda?
I am really sorry but I created a confusion in Upgrade/compatibility impact section. The proposal is not about removal of python3-dnf but about what will be called from commandline when dnf command is used. There is not a conflict between DNF5 and python3-dnf therefore they can coexist. python3-dnf even provide dnf-3 binary therefore some scripts that use repoquery and will be unable to use right now DNF5 they can still in Fedora 39 use alternative binary. Be honest in future DNF team will stop to support dnf and libdnf for Fedora but it will be subject of another proposal for Fedora 40+. We understand that the transition will be painful therefore we still keep open a window for a longer period, but it will be not opened like it was with yum (Fedora 22 - 31).
Upgrade/compatibility impact
dnf-3
yum
I am really sorry but I created a confusion in Upgrade/compatibility impact section. The proposal is not about removal of python3-dnf but about what will be called from commandline when dnf command is used.
Well, it said that python3-dnf would be obsoleted by fedora-obsolete-packages. Now it says that this can optionally happen. Can you please firmly state what's being proposed? A package isn't still available if it's obsoleted.
Also re. compatibility: will dnf system-upgrade work properly if dnf is getting replaced with dnf5 during the update? What will that look like?
dnf system-upgrade
dnf5
There is not a conflict between DNF5 and python3-dnf therefore they can coexist. python3-dnf even provide dnf-3 binary therefore some scripts that use repoquery and will be unable to use right now DNF5 they can still in Fedora 39 use alternative binary.
So those scripts will have to be modified to use dnf-3 repoquery? It seems the old /usr/bin/repoquery alias that dnf-utils currently provides will be removed completely, i.e not provided by either dnf version. As it stands, dnf5 repoquery is missing a large amount of the old functionality.
dnf-3 repoquery
/usr/bin/repoquery
dnf-utils
dnf5 repoquery
To be clear, I'm happy about the new dnf5. It fixes multiple longstanding issues! I just don't want it to be soured by a bunch of breakage.
Also: if the system has both dnf and dnf5 installed, what data will be shared between them? IIUC, the history databases are completely separate, so neither will be aware of transactions done by the other. Can this cause problems where for example dnf will be confused and not know why packages were installed by dnf5? Can we switch back and forth?
This was on the agenda for today's meeting, but we ran out of time.
Metadata Update from @mhayden: - Issue untagged with: meeting
Based on the output of today's FESCo meeting, a phased approach with checkpoints would be more helpful. For example:
These are just some general guidelines of what the phases might be.
Based on the output of today's FESCo meeting, a phased approach with checkpoints would be more helpful. For example: Add dnf5 to Fedora repos Implement support for modules Docs (especially for the new API) Port releng/infra work to new API Remove dnf4 These are just some general guidelines of what the phases might be.
Good suggestion, please where would you like to put such a phase structure? In the change proposal to scope section or somewhere else? Also I will be happy to answer all questions.
I strongly suggest proposing it on the devel mailing list (preferably in a new thread). Once it is more or less agreed on, I'd put it in the Scope or Description sections -- doesn't really matter as long as it is part of the proposal.
I strongly suggest proposing it on the devel mailing list (preferably in a new thread).
I already started a thread before I saw this. It would be great to have the DNF maintainers and more users/FESCo members chime in.
There have been some messages in the fedora-devel thread, but nothing decisive so far.
I'm very strongly in favor of the name ending up as dnf rather than dnf5. The latter is both painful as a transition and will be confusing to new users by encoding an accident of history (the version number) right in the name.
This is most important for the command-line name, but I think it would be good for the package name to also eventually be dnf.
I know I lost this fight with yum, but I still believe in the fundamentals. :)
Once dnf5 is the main implementation, it must provide /usr/bin/dnf and a dnf package. What the project is called is somewhat less important, as long as it's not visible to users. Though just calling it "dnf" would IMO cause the least confusion.
/usr/bin/dnf
Once dnf5 is the main implementation, it must provide /usr/bin/dnf and a dnf package
It should also only provide a dnf binary, not dnf5. I do not want to end up in a situation where a lot of docs are using dnf5 and adding confusion.
Hmm, I think this might be necessary for a time. Right now, the plan is to have both installed in parallel. Thus, I have both /usr/bin/dnf and /usr/bin/dnf5 installed. This is very nice for testing.
/usr/bin/dnf5
Instead of forbidding /usr/bin/dnf5 altogether, we should make it clear from the beginning that /usr/bin/dnf5 is a temporary name and that as soon as the new version becomes the default, the dnf command name should be used. (Or in other words: users should always use dnf, period.)
Then this Change is wrong. If we're "replacing" DNF with DNF5, then dnf5 should go away as a pre-requisite. The older DNF can be installed as dnf4 if we must.
dnf4
Hmm, I now noticed that we have dnf-3 already. @jmracek would it be possible to call dnf5 dnf-5 for consistency?
dnf-5
dnf-3 was a leftover of DNF being built for Python 2 and Python 3
dnf-3 binary was a workaround how to have dnf available for python-2 and 3 in parallel. I don't want to to use a presence of such a binary as something that creates a consistency problem.
Please don't take it personally but I have a feeling that discussion went into direction that is slightly different from original proposal.
We have a new product that we started to call DNF5. We find out that we cannot call it DNF because it will create a confusion and disable parallel install-ability in Fedora 38. Because parallel install-ability in Fedora 38 was a hard requirement we named it DNF5 because it states a different product, does not create problem with alternative NEVRA parsing (dnf-5 can be dnf in version 5 or only name dnf-5) and it keeps DNF in name of the package. From our point of view dnf5 was slightly better name then dnf-5. To unify name of the package with binary we named binary as dnf5.
DNF5 is a new product but we would like to provide easy transition from formal components - microdnf, yum, dnf, therefore we have a plan to provide symlinks. Also we would like to ensure that all symlinks will be present in all environment therefore we would like add symlinks to core package. It ensures that all command using yum, dnf, microdnf will work in containers, workstations and servers. I know that we can do it differently but if we want to achieve something our choices get limited.
Package naming is quite tricky and we cannot satisfy everyone. From user perspective they will see not much differences - In far future (Fedora 40+) when original dnf will be not in Fedora DNF5 will provide dnf therefore installation will continue to work, and dnf commands will be also fully functional because of symlink.
Makes sense. Please ignore my comment about dnf-5.
Yeah, to be clear: I have only medium-strong feelings about the package name, but very strong ones about the command name. I get the need for something that can work in parallel, but I do not want to invalidate all documentation and guides. The experience with yum->dnf shows that new documentation will end up with the new command, and then it gets confusing.
If we agree to and stick to dnf5 as temporary, then the docs that say dnf install are fine. If we we end up with new non-devel docs saying dnf5, that'll be messy.
dnf install
May be the question is whether we really need to change documentation when the new packager in Fedora will provide dnf5 binary and a symlink to dnf. DNF does not provide dnf binary but only symlink and I am not aware about any issue with it. We wold like to delivery DNF5 packages with one binary (dnf5), and symlinks to dnf, microdnf, and yum. We don't want to enforce users to use a different syntax. We have no plans to rename dnf5 because users of Fedora 38 will be negatively affected. We also have no plans to remove dnf, microdnf, and yum symlinks from dnf5 package, because it provides great value for our customers with very low price.
microdnf
This is good point but not easy to resolve. DNF5 is released into Fedora 38 where it must coexist with dnf. The rename in Fedora 39+ does not sound right to me. Sell DNF5 as DNF is not nice and confusing. Then there is another option - to modify documentation. But this not the first time we are faced with this problem therefore I can share our experience from YUM to DNF transition. 1. Selling DNF as YUM in version 4 (RHEL 8) It created a confusion on customer side because DNF is completely different component then YUM. Some sources were written for YUM, other for DNF. 2. Selling DNF as DNF (RHEL 9, Fedora) with compatibility to YUM It required to rewrite documentation (Replace yum by dnf), but it was the only solution how to face the confusion.
I understand that the first option sound better, but we already tried it and it was not as good as it sounds. The transition from yum to dnf happened in Fedora 22, now we are talking about Fedora 39 change to dnf5.
I don't understand - at least to me, your statements continue to be contradictory:
On the one hand, you say dnf5 will need to co-exist with dnf, because they are completely different. On the other hand, they won't be able to co-exist because dnf5 will provide symlinks for older dnfs!
First, you're saying that users will need to adapt their usage of dnf for dnf5 because they will be different and incompatible, but then you provide these symlinks - more or less claiming compatibility.
To me this sounds like you've not actually made up your mind whether to make a clean break between dnf and dnf5, which is kind of also reflected in the project's name:
If it's not dnf version 5, as you claim, then why use the name "dnf5" instead of some unrelated name? Using the name "dnf5" for something that's not supposed to be dnf version 5 but something completely new is bound to cause confusion and lead to false expectations.
In my opinion, if the dnf5 CLI is not going to be compatible with the dnf CLI, then it must not provide symlinks for /usr/bin/dnf. And it should also have a different name, but it looks like that would be reopening old wounds caused by the bungled switch from "yum" to "dnf" in RHEL ...
I don't understand - at least to me, your statements continue to be contradictory: On the one hand, you say dnf5 will need to co-exist with dnf, because they are completely different. On the other hand, they won't be able to co-exist because dnf5 will provide symlinks for older dnfs!
I am sorry for the confusion. In Fedora 38, dnf5 and dnf must coexist because dnf5 is present and dnf is the main packager. In Fedora 38 DNF5 replace mictodnf - see the other proposal https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf#How_To_Test. This proposal iis about Fedora 39 where we want to add obsolete of dnf and dnf symlink to dnf5 package.
Yes, correct we will provide compatibility to dnf. But there will be differences even in syntax that will require some changes. When yum was replaced by dnf in fedora 22, we also provide compatibility to yum by providing symlink. We want to make the change minimaly painful for user as possible. The above statements are valid commandline users. DNF API and plugins are completly different story. DNF5 will not provide any compatibility.
We cannot make clean break because it is expected that we will keep compatibility for major usercases. But we would like to improve user experience therefore we have to change things. As an example can be used upgrade-minimal command from dnf. The command is discontinues and it is replaced by option dnf5 upgrade --minimal.
upgrade-minimal
dnf5 upgrade --minimal
It is a decision of upstream community. Community decide to show the roots of the project in dnf but also demonstrate that it is a different product. There are other example of such a naming in linux - Python vs. Python3
Symlink has a value for users specially when the major usecases will stay intact. dnf install <package>, dnf remove <package>, <dnf upgrade <package> and other commands will still work with DNF5 if there will be a symlink to dnf. I've heard several times that my fingers still types yum to do operations on Fedora.
dnf install <package>
dnf remove <package>
It is a decision of upstream community. Community decide to show the roots of the project in dnf but also demonstrate that it is a different product.
This makes me nervous. This is not just any upstream project, but something that is foundational to Fedora Linux.
"We're evolving microdnf so it can replace the core features of DNF" is very different from "we're making a new package manager and calling it DNF5".
I have a good news - DNF5 is in rawhide (F38).
To be very clear -- I am not at all trying to block progress or throw up roadblocks against your work. Having this available for wide testing is great!
It's not clear to me where this stands. Is FESCo awaiting modifications to the proposal? Is the proposal updated and ready to vote?
I assumed we are waiting for an actual transition plan.
Please could you be more specific? I think everyone is waiting for a decision of FESCO to even think about transition plan of related component.
We created Fedora 39 milestone - https://github.com/rpm-software-management/dnf5/milestone/1 where community can track features planned for Fedora 39.
So far we've got a limited number of requests from community for features.
I am sorry but I have to point out that keeping the change proposal without a FESCO decision puts the whole thing into a risk. Related team are simply waiting for you to see the direction that committee plans for Fedora. The change is mainly about ownership of dnf symlink by DNF5 and if there will be good reasons to change a FESCO decision, committee is capable to revert the previous decision. In such a case, DNF5 will not own the symlink and the change will be easily reverted.
I tried my best to answer all questions, but feel free to ping me to answer anything that I overlooked or additional questions.
I also periodically update the proposal to reflect progress in project and feedback from partners.
If it helps, I'll be explicit about it:
-1, i don't think dnf5 should provide a symlink dnf -> dnf5, since it's not going to be a drop-in replacement.
dnf -> dnf5
If it helps, I'll be explicit about it: -1, i don't think dnf5 should provide a symlink dnf -> dnf5, since it's not going to be a drop-in replacement.
If the features are present, then I'm fine with CLI breakage as long as the functionality is present. It is unclear whether that would be true by the time this Change is enacted.
I think everyone is waiting for a decision of FESCO to even think about transition plan of related component.
In my world, a transition plan needs to be part of the proposal, not created after the proposal is approved.
See https://pagure.io/fesco/issue/2870#comment-818754 which was posted 2 months ago. Was this addressed? How?
OTOH this is the thing where I disagree. Once dnf5 is the default, it needs to provide the dnf command, even if the CLI API is different. We update packages in Fedora (on the release boundary) with incompatible changes all the time.
I think everyone is waiting for a decision of FESCO to even think about transition plan of related component. In my world, a transition plan needs to be part of the proposal, not created after the proposal is approved. See https://pagure.io/fesco/issue/2870#comment-818754 which was posted 2 months ago. Was this addressed? How?
Thanks for clarification.
I've updated the Scope section with feature list requested by community and with a link to upstream milestone for Fedora 39. Using external link is the only way how to keep the content in sync between multiple location.
Anyway when community will ask additional features we will modify the plan.
I assume that most affected users will only scream about missing or broken features once dnf5 is the new default and things "suddenly" stopped working. So collecting requirements in advance is going to be kind of pointless ...
We try our best to prevent any discomfort from the user side.
True, but that's beside the point. Because we don't update the package manager to an incompatible implementation all the time. It's a core system component that's tangled up in everything Fedora, including release engineering, QA, infra, end user systems, etc.
I'm sorry, but I won't change my mind, and I'll stick by my -1 vote here. You'll have to out-vote me on this one (and I reserve a free "I-told-you-so" if things inevitably go wrong) :)
OTOH this is the thing where I disagree. Once dnf5 is the default, it needs to provide the dnf command, even if the CLI API is different. We update packages in Fedora (on the release boundary) with incompatible changes all the time. True, but that's beside the point. Because we don't update the package manager to an incompatible implementation all the time. It's a core system component that's tangled up in everything Fedora, including release engineering, QA, infra, end user systems, etc. I'm sorry, but I won't change my mind, and I'll stick by my -1 vote here. You'll have to out-vote me on this one (and I reserve a free "I-told-you-so" if things inevitably go wrong) :)
Please could you be more specific about your concerns? If we know the issue we can resolve it, we are engineers and resolving problems is what we do.
We got a request from users to keep yum, and dnf symlink, because they have difficulty to learn their fingers the new binary name. The price for keeping symlinks is really low and it provides a lot of happiness around. Symlinks will not force to rewrite all documentation around and transition for many user will be more acceptable.
I'd rather make things like scripts fail with an obvious error like "file or command not found: /usr/bin/dnf", instead of making things apparently work, but possibly doing something unexpected in some cases. There's tons of scripts in the wild which rely on some specific DNF behaviour or output format - and if these change, things might continue to "work", but return garbage (or wrong) data. Making the command name different is a clear indication that "some porting may be required".
Thank you for a detailed description. I discovered that we have a lot of users that uses RHEL7,8,9, Fedora and containers at the same time therefore they have to use a different software managing software. For such a users it is nice to be able to use the same syntax for basic operation (install, upgrade, remove, ...). As I already mentioned DNF5 will provide syntax compatibility for the most frequent usages. And if users will see the similarity in syntax between DNF and DNF5 they will ask a good question - why someone decided to brake my workflows?
DNF symlink is less important for Fedora and strictly Fedora users because of the short Fedora lifecycle.
Why we want to provide in DNF5 dnf, microdnf, and yum symlinks as a mandatory feature? a) Improve user experience across different linux distribution and deployments (containers, VM, servers, workstations) - containers have dnf or microdnf installed but not both - Fedora can be deployed without a support of the yum symlink but RHEL always support it - Unifying syntax in all variants and providing compatibility with formal systems has a great value b) Compatibility - fast and less painful adoption by everyone - DNF5 will directly replace microdnf and dnf - without the compatibility the replacement will be very expensive. May be it will open the door to not adopt DNF5 but to use another Linux distribution c) RHEL distribution will request compatibility symlink and syntax - long lifecycle and overlaps with other major versions of the distribution requires it - DNF5 should provide the same feature set to all downstream including Fedora and RHEL d) All the pain with not providing compatibility will go to the DNF team head e) DNF5 is an upstream project therefore we have to gather requirements from multiple distributions and then find the solution that will be acceptable for all distribution (not too painful for anyone).
Thank you very much for your opinion. Your proposal to not provide dnfsymlink is logical and in principal correct solution (more pain in short period), but it conflicts with other requirements from other distribution (compatibility) and unifying user experience across distributions. I am really sorry but In this case we have contradicting requirements therefore we cannot satisfy everyone.
I'm putting this on the agenda for tomorrow's FESCo meeting.
To summarize my own thoughts on the matter (in no particular order):
rpm
In a broad sense, I'm +1 to this proposal. That said, "the devil is in the details" and this is a pretty fundamental part of the distribution.
Metadata Update from @sgallagh: - Issue tagged with: meeting
#info a list of things missing from dnf5 is already in preparation, let's postpone the dnf5 discussion until we see it
Metadata Update from @churchyard: - Issue untagged with: meeting
BTW it seems the change was updated including https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Acceptance_Criteria
@jmracek is the update finished, should we have a look at it or wait until you tell us to?
Whenever the update is finished, can there be an additional comment period for the revised proposal on devel@ before this is voted on by FESCo?
Highlights:
Point the symlink /usr/bin/dnf to /usr/bin/dnf5 provided by dnf5. Majority of user cases will be not affected — Same syntaxes for common commands and options Not all commands, options, or syntaxes will be supported dnf package will be obsoleted by DNF5, dnf command will be redirected to DNF5 (DNF5 will provide a symlink to /usr/bin/dnf) Original dnf-3 binary (provided by python3-dnf) will remain on the system - all functionality of dnf will be still accessible using dnf-3 binary.
Point the symlink /usr/bin/dnf to /usr/bin/dnf5 provided by dnf5. Majority of user cases will be not affected — Same syntaxes for common commands and options Not all commands, options, or syntaxes will be supported
dnf package will be obsoleted by DNF5, dnf command will be redirected to DNF5 (DNF5 will provide a symlink to /usr/bin/dnf) Original dnf-3 binary (provided by python3-dnf) will remain on the system - all functionality of dnf will be still accessible using dnf-3 binary.
I think some syntax changes are unavoidable and will need to be done when things are cleaned up. Let's just keep avoidable changes and removals to a minimum.
Highlights: Point the symlink /usr/bin/dnf to /usr/bin/dnf5 provided by dnf5. Majority of user cases will be not affected — Same syntaxes for common commands and options Not all commands, options, or syntaxes will be supported dnf package will be obsoleted by DNF5, dnf command will be redirected to DNF5 (DNF5 will provide a symlink to /usr/bin/dnf) Original dnf-3 binary (provided by python3-dnf) will remain on the system - all functionality of dnf will be still accessible using dnf-3 binary. I think some syntax changes are unavoidable and will need to be done when things are cleaned up. Let's just keep avoidable changes and removals to a minimum.
I agree, we have plan to keep syntax when there is not strong reason for the change. As example I can use optional positional argument for history command. With DNF4 you can use - dnf history dnf to list all transactions where dnf was preset. Try the same for info package and you will get surprize - dnf history info will not show information about info package but it changes type of the output. To list transaction with info package dnf history list info. In DNF5 positional optional argument or optional subcommand will ge replace by more solid syntax - always requirement of specification of subcommand.
dnf history dnf
info
dnf history info
dnf history list info
BTW it seems the change was updated including https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Acceptance_Criteria @jmracek is the update finished, should we have a look at it or wait until you tell us to?
I will send the note when the rewrite is finished
The rewrite is finished, please feel free to provide additional comments and suggestions.
Tagging for next week's meeting.
Metadata Update from @bcotton: - Issue tagged with: meeting
Just a note: I opened a discussion related to the package naming, commandline tool naming, man pages, and guidelines - https://github.com/rpm-software-management/dnf5/discussions/210. The purpose of that discussion is to find out the best approach how to deploy the next generation of software management tool. The community likes approach which will keep dnf (command examples) in Fedora guidelines and in man pages. This approach should resolve @mattdm concerns.
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-10/fesco.2023-01-10-17.00.html
ACTION: dcantrell will post to devel@ to trigger dnf/dnf5 discussion (Eighth_Doctor, 17:25:19)
The post was made, and there was a bit of fresh discussion. Let's vote on this today.
Metadata Update from @zbyszek: - Issue tagged with: meeting
Let's vote on this today.
Let's vote asynchronously, please. I won't be able to follow the discussion before the meeting and there is no rush, this is a F39 change.
OK, let's vote here then.
Metadata Update from @zbyszek: - Issue untagged with: meeting
A week has (almost) passed, and there are only 2 votes. The voting is extended one week more.
@kevin, @decathorpe, @sgallagh, @music, @mhayden, @ngompa, @churchyard: please cast.
Casting +1.
Let's go for it.
@romulasry I removed your comment and Neal's, to avoid clutter. But this unsubscribed you again. So I'm making this comment now ;)
onward!
I had said in https://pagure.io/fesco/issue/2870#comment-829775 that I was "broadly +1", but I can make it clearer.
After an additional week, the vote is APPROVED (+6,0,-0)
Metadata Update from @bcotton: - Issue tagged with: pending announcement
Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M63NEXR24HVB2RJ5XUBTQTGYLBLNBTRC/
Metadata Update from @zbyszek: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
This Change made an additional change not described in the proposal - dnf5 no longer defaults to skip_if_unavailable=True in Fedora (which was an override of the upstream config that we shipped for many years). This change presents a concern for desktop users using third-party repos, because an inaccessible such repo would prevent all system updates. More details can be found in bug 2216205.
skip_if_unavailable=True
@jmracek seems to be saying "we no longer want to ship it, but somebody else can ship it (once we reimplement our config handling)". It's true that with the new approach, interesting things can be done, i.e. the defaults can be different for desktops vs the server. My concern is that this wasn't communicated at all, it's not described in the proposal, it wasn't discussed, and the affected parties (e.g. editions and spins owners) weren't asked to provide their defaults and agree on how to actually technically do it (which package should carry the override, etc). @jmracek also unfortunately stopped responding, he might be on vacation.
So I just want to notify you that this issue exists. It's not just something to be resolved in dnf itself, it looks like it'll need participation from other teams as well.
Yeah, that's a pretty obvious regression from previous behaviour :(
What I don't understand is why dnf5 can't carry this is in the default configuration? IMO that's the only place where setting this config actually makes sense, if we want to keep behaviour consistent with Fedora < 39.
My understanding is that they want dnf.conf empty, because it will probably have the highest priority (overriding drop-in configs). But they should still be able to ship skip_if_unavailable=True in a dnf.conf.d drop-in config as part of the dnf package, i.e. globally. I think that would be a reasonable fallback solution if the "let each edition choose their own defaults" approach didn't work out. It's just not specified anywhere, and @jmracek needs to confirm whether there aren't any technical hurdles to this.
dnf.conf
dnf.conf.d
Plus, also it changed best option to true by default (https://bugzilla.redhat.com/show_bug.cgi?id=2219153) which was rejected in https://fedoraproject.org/wiki/Changes/DNF_Default_Best
best
true
Oof. That's not a good look. :weary:
Considering how many things are still broken with dnf5 mere days before the mass rebuild (Fedora CI is broken, fedora-review is broken, regressions of default behaviour like switching skip_if_unavailable or best settings, etc.), I'm beginning to think that we need to pull the plug and postpone this to F40.
skip_if_unavailable
This change was discussed during today's FESCo meeting: ACTION: decathorpe to open a ticket about dnf5-for-f39 roadmap and possible contingency actions
Filed: https://pagure.io/fesco/issue/3039 Also posted to the devel list for better visibility.
It's a shame that Change page doesn't seem to have links to a tracker bug or FESCo issue, so we can't see the discussion...
Back when I was a younger, more inexperienced FPgM, I (usually) put the issue links in the comments when I submitted a proposal to FESCo. So I can tell you that this was #2168. Eventually, I learned that it's better for everyone to put it in the body. In the interests of posterity, I have added that link (and added the relatively-new {{Change_Rejected_Banner}} to indicate that it was a rejected proposal. And they say you can't teach an old bcotton new tricks!)
{{Change_Rejected_Banner}}
Since it was rejected, there wouldn't have been a tracker bug (at least not created by me).
Login to comment on this ticket.