This thread suggests that using DNF5 works, using the command suggested by “Joe” (in the lower part of the comment):
There’s also ongoing work by the Fedora team on figuring out exactly what to do with this incompatibility situation with the transition from DNF4 to DNF5. So for future users finding this thread, this stuff might change.
Regarding the use of dnf-3 and dnf4 (suggested in the other thread), I think, if I’m not mistaken, that it’s not adviced to mix DNF3/4 and DNF5 (the latter was deployed and made default in Fedora 41, using the same dnf command as before). The issue with the mixing of different DNF implementations was, according to memory, that the ownership of updates could cause issues with management of updates and dependencies (and repositories?). There might be other possible reasons why you’d want to avoid this. There might be exceptions for this, as this specific scenario. Correct me if I’m wrong.
I don’t think splitting the thread was a good decision. Can you move it back, please?
Splitting the thread makes the information fragmented and users coming across the other thread (both now and in the future) will be presented with lacking and incorrect information.
This new thread won’t necessarily be returned in search results and having to open even more threads to get the full picture is unecessary and cluttersome in my opinion. This new thread is also confusing to anyone finding it as it lacks context.
As for config-manager being implemented in DNF5, it didn’t fix the issue and even if it did the information provided is still relevant and on topic. I would argue it’s necessary as the other thread is lacking and confusing and this helps clearing it up. Especially if someone can provide additional context and information, and confirmation to the questions.
I don’t see the purpose of splitting the thread when the information added is relevant and clears up potential incorrect or lacking information. It also cuts off the discussion, that could potentially lead to more clarity, as opposed to making it incomplete.
not sure I can revert the action (never done, not seen a function for that).
The issue I see with the previous, old post is that it was referring to config manager when it didnt exist in dnf5 or at least wasn’t documented. Now, there is config-manager and documentation, so the answer is a different one than it was 1 year ago.
Thanks for the reply and for considering my feedback.
I don’t think the change of situation with DNF5 and config-manager changes anything, it just means there is a more complete solution to the to thread that isn’t being added, leaving it lacking of a solution and with incomplete context.
The root of the topic still remains and getting the complete picture is very useful to understanding both the problem presented in the thread as well as potential solutions (different solutions have different pros, cons and implications).
I’ve experienced too many times when looking up solutions or information on an issue that the thread is closed and there actually is a need for more information or it wasn’t fully solved to begin with. Sometimes threads like these are helpful either with related issues or topics or to simply get an understanding of the components involved.
Leaving the thread open and available for information (independent on thread age) is in my opinion quite beneficial and useful. Not only for information archival but also when searching up info about related topics or edge-cases where you have an old system or need to fully understand how to deal with outdated instructions and commands.
And especially since the solution and context isn’t complete.
Thanks, this is useful. The links provide additional information and would benefit the other thread this was split from.
The way I see it, there are two angles to this issue. The first one being how DNF5 deals with these legacy commands and how it could operate appropriate to spec prior to fixes/enhancements being implemented. Then there’s the second angle of Brave’s incorrect instructions. Both angles needs addressing, in my opinion. Both angles are useful and acts a red thread for others.
When DNF5 is able to deal with this, it’ll still be useful to have the issue and solution and development documented (I often find info about deprecated stuff I need to be aware of by reading threads like that).
When the Brave instructions are fixed, there will still be people getting commands from articles (how to), documentation in other projects or personal documents referrencing commands. And also just people’s old systems, various edge-cases etc.
If it’s impossible to revert, is it an option to re-open the thread and I can re-add the comment? Along with a reference to the useful information links from Joe here.
I don’t believe reopening the old topic from more than a year ago is the right thing. Both threads are linked at the time they were split and it is a single click to see the other when one is already open.
Why does it matter how old it is? The usefulness of information has no expiration date.
And while a user could click on the “split thread” link, the users might not even notice it or just assume it was unrelated since it was split. And most people tend to avoid digging deep. Often, they try one or two suggestions and then give up if it doesn’t work. Most people don’t open multiple threads and compare the answers and read up to get a complete understanding. That’s one of several reasons why completeness and usefulness of threads is important.
Besides, like I explained above, I don’t the purpose of splitting in the first place, as the split comment provides the actual solution (courtesy of Joe), which was missing in the thread. The current solution is more of a temporary workaround and doesn’t follow the DNF specification.
It matters tremendously in the case of dnf5. That thread even had a solution marked so many would see that and not even look at the later necro posts that followed a year and half later. If they did then the link at the bottom leads to this thread that is related but much more current.
The development team did not even consider it ready for full deployment until the release of f41.
What was true of dnf5 in July 2023 was that it was in early stages of development and was not even available for fedora 38 and had very limited usability on fedora 39.
Splitting the thread so comments made today are related to use of dnf5 after it was ready for release is totally appropriate.
The information is not gone, but closing makes it impossible to add more information or corrections. Situations may change in the future and in this case it was already known that the proper solution was not added in the thread, but rather a workaround.
Situations changing is the exact reason why threads should remain open, imo. In this instance, the situation is not even concluded and it is lacking of information and context; it’s incomplete. If something ends up not being true anymore, then the thread will account for that and why, it won’t change the or take away from the thread’s roots. Rather the contrary, additions will add to it and complement it. This is pretty common on sites like StackExchange where new solutions and developments are posted, sometimes many many years later. And it’s super useful. If those threads were being closed after the initial solutions, they would in many cases become dead-ends or simply threads of low value and usefulness. I don’t think there’s anything wrong with treating threads as something evolving.
I think there should be a high bar for closing issues. I understand it if there is figthing or inappropriate behaviour that cannot be resolved, or if there are “100 pages” of discussion, but otherwise I just don’t see the usefulness in closing threads.
Closed threads may (and often do) present users with inaccuracies or confusion, either because it’s a dead-end or it’s impossible to add to it. The StackOverflow example demonstrates the benefit of keeping threads open. It also demonstrates that it a forum can function well with such a philosophy.
I don’t think it does. I think this is a good example of when threads should remain open.
The solution in the thread was a workaround. I mean no offence to the other comments, just to be clear about that, but I think we can both agree that the preferred solution is one that utilizes and follows the spec of DNF5. One that doesn’t call on utilities that have been deprecated.
A workaround is good while waiting for a better solution, but that doesn’t mean it should be set in stone with no way of correcting or improving it, in the form of adding to the thread.
When better solutions arrive, there’s no reason to keep them from being available and seen where users will arrive from a search engine.
many would see that and not even look at the later necro posts
Some would, but additional comments wouldn’t have a negative effect on these individuals. On the other hand, keeping additional comments from being added would negatively affect those who actually do read through threads. Some will read 20 comments, some will read 50. Some will read 100 or read it all regardless of comment count.
And some users will quickly glance at the latest comments to see if there has been any changes to consider.
Some users will even do Ctrl + F.
If one is to close threads because “many users will only click the shortcut to the solution and not read further”, then it will be at the expense of those who actually do read further. The users just reading the solution don’t benefit from closed threads.
What was true of dnf5 in July 2023 was that it was in early stages of development and was not even available for fedora 38 and had very limited usability on fedora 39.
And eventually, the situation improves and the thread may improve with it.
I found that thread because I got the same error. I’m running Fedora 41 and I updated the system with a reboot before running the commands.
The problem is still there and there’s a solution for it. The thread was missing that solution. So adding this solution only improves the thread without taking away from it, especially when the thread doesn’t even have double digit comment amount.
Splitting does the same thing with the links that are automatically provided.
Keeping a thread open endlessly can bury the solution in an extended length thread and readers get tired of just reading on and on in an attempt to understand and follow the discussion. Closing necro threads that are based on old EOL releases of fedora is appropriate. Opening new threads, even on the same topic, are then related to versions of fedora that are current and relevant.
There even is one thread currently open because the user is having problems with upgrading from a fedora release that is now a year EOL.
You can click on “select posts” in the tl4/mod tool button menu (at least, I think TL4 have the same tool button?) on the right in the topic, then “select all” and then move them all to the the “existing topic”. Once you selected the existing topic, you can choose below if you tick “preserve chronological order after merging” or not.
I have never used that, but I expect that it will just merge both in the way you want them to be sorted.
However, since this topic has now 16 posts that I assume do not always consider the other topic and its development (I didn’t read through it), I am not sure if anyone here has still an interest to merge them (?). I could imagine that this will cause a lot of confusion.
The problem with this approach is that it’s not very visible and is also unecessary to begin with (this is my opinion, of course). It will also give the impression that it’s unrelated and not what the user is looking for.
One of the primary purposes of such a forum management tool (thread splitting) is separating unrelated or off-topic content. I would argue that this is also the intuitive interpretation when a user see a message stating that the thread was split.
I agree that long-winded threads that seem to go nowhere absolutely can take away from the useful comments, but this is very far from being a long-winded thread. It currently has 4 comments.
EOL or not, search results will direct to it and the issue still exists on F41 right now. And it will still benefit from additional information, especially as it’s only a 4-comment thread. Also, there’s no indication that this thread is an EOL release-only thread. The poster doesn’t state OS details and it’s not intuitive for all users to know the release schedule history by heart, especially not release-specific changes. A user finding this thread might not even know if they’re running DNF5 or that it used to not being DNF5. It’s also possible that EOL releases get improved solutions in the future.
It would surprise me if such an unresolved thread wasn’t open, honestly.
This thread (besides the split first comment) is pretty much about the splitting decision. I proposed to re-add the information, as the moderator said they didn’t know if merging back was possible. They agreed to that and I will add some more info soon.
I strongly (and respectfully) disagree. I am an actual user who found that thread when having the exact same issue on the latest F41 update.
What was confusing was the discrepency between threads and lack of additional information. Too many questions unanswered. Which sent me on a thread and information hunt to figure out what’s what.
And I already knew about and followed DNF5 and isn’t a novice. I can only imagine novice users coming to that thread while running F41 and DNF5 and running those commands, which are not per spec. This is, at it’s core, essential to my reasoning why the thread indeed needed additions.
An additional and often used reason, such as this case, is to avoid reopening necro threads as well as having the discussion related to current software and not just lingering on after a thread has been ignored (and even closed) more than a year past.
Experienced forum members much prefer that threads are current and related to supported versions of the OS.
It has already been stated that there have been major changes to dnf5 since that original thread was opened so discussion continuing there would be muddied by the fact that the initial problem was an immature software package. Dnf5 is much more mature now and the discussion should be based on the current status.
Post 2 even linked to the current documentation so this discussion really is moot.
Has the actual question related dnf config-manager and bravebeen answered? In that case mark an answer as solution and can discuss moving/splitting topics in a separate, new thread. Thank you.
Can you move it back, please? 
Both angles are useful and acts a red thread for others.
