Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Dear community,
I would like to mentioned that there is last chance (about a week) to comment 
the updated proposal and discussion on DNF5 github before FESCO will make a 
decision.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Because the naming of the tool is upstream decision I opened a discussion 
https://github.com/rpm-software-management/dnf5/discussions/210. DNF and the 
new tool is shipped into multiple upstream therefore we have to collect 
feedback from multiple distribution and upstream discussion channel is the bet 
place for that. I asked there several question and I provided 3 basic scenarios.

```
What name (**dnf**, yum, **dnf5**, or microdnf ) we should use for package 
providing binary (currently DNF5)?
What binary name or symlink we should use in man pages (currently DNF5) for 
examples?
What binary name or symlink we should use in Fedora guidelines?
What binary name or symlink we should use in RHEL guidelines?
How we should name packages containing plugins (additional command)?
```

Best regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 21. 12. 22 v 18:45 Chuck Anderson napsal(a):

On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]

Let me put together a few points to sum this up:

1) DNF name is well established, keep the DNF name (and forget about YUM).

2) Keep the compatibility on reasonable level. 100% compatibility is myth
(even between the tiniest updates).

3) Changes are inevitable, especially between major versions. That is why we
version, right? While nobody likes them (especially breaking changes), they
are accepted. Please don't be afraid to do them for good!

4) Keep the package name, so if somebody don't want to update, they can do
`dnf update --exclude dnf` instead of looking for new package name to do
`dnf update --exclude dnf5`

5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
user want to combine these, unless they are desperate. Don't bet everything
on this.

6) Keep only one instance of documentation, if needed, document the old
behavior

7) Tooling and framework changes on background are unimportant to end users.

This is a very good summary of my opinion as well. Thanks, Vit!

Is the command line tool for DNF version 5 called /usr/bin/dnf?  Or
will users have to learn to use "dnf5 install ..." etc?  If the
latter, I think it is a bad idea.



Luckily the former should be the case, IOW `dnf` command stays.


Vít



Each time a new version of "ls"
comes out, they don't append a new digit to the command.  Users
shouldn't have to learn a new command name just to upgrade to a new
major version of a command.  If the syntax and functionality is
substantially the same, then the command name should remain the same.

If the UX (user experience) is sustantially changed such that a user
would have to learn a completely new syntax in order to use it, then
perhaps it would be better to rename the whole product/command to
something other than DNF.  For example, when we moved from
initscripts/service/chkconfig to systemd, the syntax changed enough
that it made sense to have a new command "systemctl" to replace the
previous commands "chkconfig" and "service".

As for the RPM package name, that is less important because it doesn't
really affect the UX much.  Guidance here should be taken from the
packaging guidelines.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Examples:

 The python-sqlalchemy package occasionally has multiple versions
 in Fedora for backwards compatibility. The most current version of
 python-sqlalchemy is named python-sqlalchemy and an older
 supported version is python-sqlalchemy0.5. No delimiter is used in
 this situation.

This seems to suggest that the package name should be "dnf" for the
latest version and "dnf4" for the previous version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Chuck Anderson]

On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
> [...]
> > Let me put together a few points to sum this up:
> > 
> > 1) DNF name is well established, keep the DNF name (and forget about YUM).
> > 
> > 2) Keep the compatibility on reasonable level. 100% compatibility is myth
> > (even between the tiniest updates).
> > 
> > 3) Changes are inevitable, especially between major versions. That is why we
> > version, right? While nobody likes them (especially breaking changes), they
> > are accepted. Please don't be afraid to do them for good!
> > 
> > 4) Keep the package name, so if somebody don't want to update, they can do
> > `dnf update --exclude dnf` instead of looking for new package name to do
> > `dnf update --exclude dnf5`
> > 
> > 5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
> > user want to combine these, unless they are desperate. Don't bet everything
> > on this.
> > 
> > 6) Keep only one instance of documentation, if needed, document the old
> > behavior
> > 
> > 7) Tooling and framework changes on background are unimportant to end users.
> 
> This is a very good summary of my opinion as well. Thanks, Vit!

Is the command line tool for DNF version 5 called /usr/bin/dnf?  Or
will users have to learn to use "dnf5 install ..." etc?  If the
latter, I think it is a bad idea.  Each time a new version of "ls"
comes out, they don't append a new digit to the command.  Users
shouldn't have to learn a new command name just to upgrade to a new
major version of a command.  If the syntax and functionality is
substantially the same, then the command name should remain the same.

If the UX (user experience) is sustantially changed such that a user
would have to learn a completely new syntax in order to use it, then
perhaps it would be better to rename the whole product/command to
something other than DNF.  For example, when we moved from
initscripts/service/chkconfig to systemd, the syntax changed enough
that it made sense to have a new command "systemctl" to replace the
previous commands "chkconfig" and "service".

As for the RPM package name, that is less important because it doesn't
really affect the UX much.  Guidance here should be taken from the
packaging guidelines.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Examples:

The python-sqlalchemy package occasionally has multiple versions
in Fedora for backwards compatibility. The most current version of
python-sqlalchemy is named python-sqlalchemy and an older
supported version is python-sqlalchemy0.5. No delimiter is used in
this situation.

This seems to suggest that the package name should be "dnf" for the
latest version and "dnf4" for the previous version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]
> Let me put together a few points to sum this up:
> 
> 1) DNF name is well established, keep the DNF name (and forget about YUM).
> 
> 2) Keep the compatibility on reasonable level. 100% compatibility is myth
> (even between the tiniest updates).
> 
> 3) Changes are inevitable, especially between major versions. That is why we
> version, right? While nobody likes them (especially breaking changes), they
> are accepted. Please don't be afraid to do them for good!
> 
> 4) Keep the package name, so if somebody don't want to update, they can do
> `dnf update --exclude dnf` instead of looking for new package name to do
> `dnf update --exclude dnf5`
> 
> 5) I certainly wont combine DNF 4 and DNF 5 on one system. I don't think any
> user want to combine these, unless they are desperate. Don't bet everything
> on this.
> 
> 6) Keep only one instance of documentation, if needed, document the old
> behavior
> 
> 7) Tooling and framework changes on background are unimportant to end users.

This is a very good summary of my opinion as well. Thanks, Vit!

Best regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 21. 12. 22 v 11:40 Jaroslav Mracek napsal(a):

I am really sorry, but could we start the discussion from beginning? We use 
many personal opinion but we provide very limited set of facts.

I will try to summary some facts related to the naming topic.

We developed a new software management tool to replace DNF, MICRODNF, DNF 
libraries and potentially PackageKit.As you can see it is supposed to replace 
multiple tools (step by step) therefore picking the right name is not easy, but 
`DNF` is the strongest player here.

If we will keep the name `DNF` for the new tool



This is where our views differ. You call it new tool, because you have 
probably rewrote everything, for me it is still DNF.




we will get some benefits. The documentation will stay intact, people will not 
get scared of the tool change. But as negative we will create incorrect 
impression of using the same tool, feature set or compatibility. The new tool 
will not provide all features, command, options from DNF. Some features will be 
implemented after an user request to ensure someone is still using them. It 
will not support old plugins and even not Python plugins - I want to say that 
it is a significant changes.



This is nothing extraordinary for major version. If you changed on 
background from Python to C++, it is probably big change for you as a 
developer, but for me as a user, I mostly don't care.




Why I think that incorrect impression could happen. Because we get such a 
request from users of RHEL8 where we keep YUM brand. And YUM (DNF in 
background) in RHEL8 is very similar to YUM in RHEL7. To create a strong YUM 
compatibility layer it required additional 3 years of development after replace 
of YUM in Fedora 22.  I understand that the name change can be confusing but we 
tried with DNF both approaches - ship the new tool with a different name - DNF
   (Fedora) and ship it as formal tool YUM (RHEL8) and from received feedback, 
RHEL8 approach was worse. And it is a reason why DNF is shipped as DNF in 
RHEL9. It required to rewrite the whole documentation from YUM to DNF but it 
was worth to do it.

What we learned from Fedora deployment? Don't create any warning when people 
keep using the old tool name - YUM.



YUM name should have been kept, but that is history. DNF is here for a 
decade (wow) already, I cannot care less about YUM. Nobody in Fedora 
cares about YUM. Nobody in RHEL 10 will care about YUM and most people 
onboarding on RHEL 9 are well aware there is DNF and it is pretty 
compatible from user POV.





Please if you have any example where a significantly different tool shipped 
with the name of the old one was successful please share it with us.



You can look at the recent discussion about ImageMagic.

Gnome changes and evolves. There were quite a lot of changes on the 
background.


Every language changes. It does not matter if you talk about C / Python 
/ Ruby. The languages typically don't rename just because they release 
new major version (but I would not use Python as a good example here, 
the python3 at this stage is not any better then dnf5).





If we will ship the new tool as DNF we will loose additional feature - back up 
option for users that want to use original DNF in Fedora 39.



Again, it is nice that you consider backup option. But backup is what 
backup is, i.e. tool when you have no other option. Using both at the 
same machine will be far from ideal. I certainly don't want to use these 
two in parallel, because they use separate DBs. This is important for 
me, because I do care about history of my computer. So if it should be 
broken, then I will break it once and never look back. For new 
installations, I cannot imagine you would suggest to have two versions 
of DNF installed in parallel.


From my POV, you put too much stress on the parallel / backup options. 
DNF 5 is either ready for prime time or not.




As I mentioned original DNF package will remain in distribution therefore if 
anyone need to use the original DNF they can upgrade from Fedora 38 without 
replacing the DNF. They only need to exclude the new tool from transaction. 
With using a different name it is still not impossible, but it will require 
rename of original DNF package and somehow inject it into transaction - not 
nice from my point of view but possible.



I probably don't understand. If I'd like to keep using DNF 4, then I'd 
excluded the update to DNF 5. But how anybody is supposed to know that 
instead of excluding "dnf", they should exclude "dnf5". I still don't 
understand this.





If we will ship the new tool with a new name we will clearly highlight that it 
is a new tool and that it requires more attention (testing) from user side and 
community.



Majors versions are what they are. They break things. Change of the 
(package) name breaks even more things.




On the other hand it will require to modify documentation, but it will also 
help to distinguish between dnf version 4 and version 

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

I am really sorry, but could we start the discussion from beginning? We use 
many personal opinion but we provide very limited set of facts.

I will try to summary some facts related to the naming topic.

We developed a new software management tool to replace DNF, MICRODNF, DNF 
libraries and potentially PackageKit. As you can see it is supposed to replace 
multiple tools (step by step) therefore picking the right name is not easy, but 
`DNF` is the strongest player here.

If we will keep the name `DNF` for the new tool we will get some benefits. The 
documentation will stay intact, people will not get scared of the tool change. 
But as negative we will create incorrect impression of using the same tool, 
feature set or compatibility. The new tool will not provide all features, 
command, options from DNF. Some features will be implemented after an user 
request to ensure someone is still using them. It will not support old plugins 
and even not Python plugins - I want to say that it is a significant changes. 
Why I think that incorrect impression could happen. Because we get such a 
request from users of RHEL8 where we keep YUM brand. And YUM (DNF in 
background) in RHEL8 is very similar to YUM in RHEL7. To create a strong YUM 
compatibility layer it required additional 3 years of development after replace 
of YUM in Fedora 22.  I understand that the name change can be confusing but we 
tried with DNF both approaches - ship the new tool with a different name - DNF
  (Fedora) and ship it as formal tool YUM (RHEL8) and from received feedback, 
RHEL8 approach was worse. And it is a reason why DNF is shipped as DNF in 
RHEL9. It required to rewrite the whole documentation from YUM to DNF but it 
was worth to do it.

What we learned from Fedora deployment? Don't create any warning when people 
keep using the old tool name - YUM.

Please if you have any example where a significantly different tool shipped 
with the name of the old one was successful please share it with us.

If we will ship the new tool as DNF we will loose additional feature - back up 
option for users that want to use original DNF in Fedora 39. As I mentioned 
original DNF package will remain in distribution therefore if anyone need to 
use the original DNF they can upgrade from Fedora 38 without replacing the DNF. 
They only need to exclude the new tool from transaction. With using a different 
name it is still not impossible, but it will require rename of original DNF 
package and somehow inject it into transaction - not nice from my point of view 
but possible.

If we will ship the new tool with a new name we will clearly highlight that it 
is a new tool and that it requires more attention (testing) from user side and 
community. On the other hand it will require to modify documentation, but it 
will also help to distinguish between dnf version 4 and version 5. Using the 
same name in documentation is a trap for user using Google. I will search how 
to do something in Fedora but I can get a reference for DNF-4 tool therefore it 
could be not functional.

Could we rename the new tool back to DNF? Yes, we could but do we want it? Or 
do we want to rename DNF in Fedora back to YUM? Right now we could, because DNF 
is feature complete, very compatible with YUM.

There is also the last fact - DNF team is responsible for the new tool and all 
problems related to the change is going to our direction. If there will be a 
complain about the new tool, or the naming we cannot blame anyone because we 
have rights to say no, or don't we?

Please if you have other opinion related to the proposal, please don't hesitate 
to share it, but please provide facts, user cases and examples or examples from 
other tools. If we will know the issue related with the proposed approach we 
could find a way how to resolve it or document the problem as known issue.

Best regards

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Barry Scott]

> On 19 Dec 2022, at 16:50, Jaroslav Mracek  wrote:
> 
> I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to 
> YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as 
> DNF, because it creates a confusion. And I don't want to experience the same 
> issue twice. I understand that the name change is always not nice, but 
> keeping the same name for a different tool is worse.

I'm using Oracle Linux 8 at work and some older scripts use "yum" and newer 
scripts use "dnf" this all just works.

What is the confusion that you are trying to avoid?

The only issue that I recall from earlier in the thread is that dnf version 5 
is not feature complete enough to replace dnf version 4.

Is there any database that is corrupted if dnf v4 and dnf v5 commands are mixed 
on a system?

Barry


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kalev Lember]

On Tue, Dec 20, 2022 at 2:16 PM Vít Ondruch  wrote:

> Good to know. Thx. Please tell me that part of the plan is renaming dnf5
> => dnf and I'll shut up.
>

I second to this. While it makes sense to temporarily introduce a parallel
installable dnf5 to enable easier early testing, I think dnf5 should get
renamed to dnf when it's made the default. Anything else is just super
confusing.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 19. 12. 22 v 17:50 Jaroslav Mracek napsal(a):

I am still very much against the `dnf5` package name and I have uneasy
feelings reading (in my words) "`/usr/bin/dnf` symlink will change from
`/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break
so basic assumption such as `rpm -q dnf`. It won't really work even when
`rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.

Please give Fedora DNF version 5 instead of DNF5. Please reconsider the
package name, especially when the "Obsolete dnf package by dnf5" is
still part of the plan. There is still time to update the proposal.

I am really sorry but I don't see a way how we can ship DNF5 as DNF package. 
The reason is quite simple. We already ship DNF5 in Fedora 38 as DNF5.



Please don't use this argument. I was objecting introducing dnf5 package 
at the time it was reviewed:


https://bugzilla.redhat.com/show_bug.cgi?id=2120661#c14

Now the existence of dnf5 is the reason why we can't do something?



  In Fedora 38 we need parallel installability with DNF and we cannot rename 
DNF as something else.



I don't think you focus on the right thing. Parallel installabilility is 
not useful for anything except testing, mainly because the history gets 
broken with all the side effects. I understand that the upgrade needs to 
break something to improve thins for the long term, so I accept this 
breakage. But just one time. I can't imagine using DNF and DNF5 in 
parallel long term for anything useful.




  I also remember RHEL8 where we ship DNF as YUM. And DNF is very similar to 
YUM - both are Python based tool. Anyway in RHEL9 the same tool is shipped as 
DNF, because it creates a confusion. And I don't want to experience the same 
issue twice. I understand that the name change is always not nice, but keeping 
the same name for a different tool is worse.



I was pointing this elsewhere. But if you really learned from YUM => 
DNF, then you would never mentioned DNF5, but DNF version 5. There would 
never be dnf5-5.0.1-1.fc38 package, but dnf-5.0.1-1.fc38. It seems to me 
that you are saying something while doing something completely 
different. This is confusing to me.



  

BTW it would also help if you sketched out what is the timeline and
process to deprecate DNF 4.x.

I have a plan to open a system wide change to remove DNF for Fedora 40.



Good to know. Thx. Please tell me that part of the plan is renaming dnf5 
=> dnf and I'll shut up.



Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> I am still very much against the `dnf5` package name and I have uneasy 
> feelings reading (in my words) "`/usr/bin/dnf` symlink will change from 
> `/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break 
> so basic assumption such as `rpm -q dnf`. It won't really work even when 
> `rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.
> 
> Please give Fedora DNF version 5 instead of DNF5. Please reconsider the 
> package name, especially when the "Obsolete dnf package by dnf5" is 
> still part of the plan. There is still time to update the proposal.

I am really sorry but I don't see a way how we can ship DNF5 as DNF package. 
The reason is quite simple. We already ship DNF5 in Fedora 38 as DNF5. In 
Fedora 38 we need parallel installability with DNF and we cannot rename DNF as 
something else. I also remember RHEL8 where we ship DNF as YUM. And DNF is very 
similar to YUM - both are Python based tool. Anyway in RHEL9 the same tool is 
shipped as DNF, because it creates a confusion. And I don't want to experience 
the same issue twice. I understand that the name change is always not nice, but 
keeping the same name for a different tool is worse.
 
> BTW it would also help if you sketched out what is the timeline and 
> process to deprecate DNF 4.x.

I have a plan to open a system wide change to remove DNF for Fedora 40.

> 
> 
> Vít
> 
> 
> 
> Dne 19. 12. 22 v 16:24 Vít Ondruch napsal(a):

Best regards

Jaroslav Mracek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

I am still very much against the `dnf5` package name and I have uneasy 
feelings reading (in my words) "`/usr/bin/dnf` symlink will change from 
`/usr/bin/dnf-3` to `/usr/bin/dnf5`". This name change is going to break 
so basic assumption such as `rpm -q dnf`. It won't really work even when 
`rpm -q dnf5` output was `dnf5-6.0.0-1.fc43.noarch`.


Please give Fedora DNF version 5 instead of DNF5. Please reconsider the 
package name, especially when the "Obsolete dnf package by dnf5" is 
still part of the plan. There is still time to update the proposal.


BTW it would also help if you sketched out what is the timeline and 
process to deprecate DNF 4.x.



Vít



Dne 19. 12. 22 v 16:24 Vít Ondruch napsal(a):

Thx for heads up. I assume this is the diff:

https://fedoraproject.org/w/index.php?title=Changes%2FReplaceDnfWithDnf5=revision=663558=655776 




Vít


Dne 16. 12. 22 v 12:11 Jaroslav Mracek napsal(a):
I've rewritten the proposal to make it clear what it is about 
including additional information that were unknown before. I hope 
that I've addressed community suggestions and remove the confusion 
with original proposal. Please feel free to comment the new proposal 
and discuss the new content of the proposal.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Thx for heads up. I assume this is the diff:

https://fedoraproject.org/w/index.php?title=Changes%2FReplaceDnfWithDnf5=revision=663558=655776


Vít


Dne 16. 12. 22 v 12:11 Jaroslav Mracek napsal(a):

I've rewritten the proposal to make it clear what it is about including 
additional information that were unknown before. I hope that I've addressed 
community suggestions and remove the confusion with original proposal. Please 
feel free to comment the new proposal and discuss the new content of the 
proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 23 November 2022 at 11:38, Jaroslav Mracek wrote:
[...]
> > I understand that deprecation warning has their own issues, but if you 
> > already put some thoughts into that topic, I'd like you to elaborate 
> > more then just provide statements like above.
> 
> DNF in early versions (1.1) provided a warning when `yum` was called.
> It was nice and transparent way how to send a message about
> redirection to DNF, but we got very strong negative feedback about
> that, therefore we removed it. I don't think we should repeat that
> approach. Personally I don't feel comfortable with education of our
> users using warnings, because they have value at first occurrence but
> then they are annoying.

Why don't you make them one-time only, then? I.e. drop a file in user's
home directory, e.g. ~/.config/dnf5/dnf-warning-displayed or something
and not display the warning if the file is there.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

I've rewritten the proposal to make it clear what it is about including 
additional information that were unknown before. I hope that I've addressed 
community suggestions and remove the confusion with original proposal. Please 
feel free to comment the new proposal and discuss the new content of the 
proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Dne 25. 10. 22 v 14:00 Jaroslav Mracek napsal(a):
> 
> 
> That is nice, but honestly who reads man pages? And especially who reads 
> man pages of SW they are not using (assuming that the manpage will be 
> part of DNF5 and not DNF).

Thank you for very much for a good point. We already played with this topic for 
DNF but that game was primary focused for RHEL and required by RHEL, therefore 
it was delivered to Fedora after many users already accepted DNF. If you type 
`man yum` you will get man pages for DNF with note that ` yum - redirecting to 
DNF Command Reference`. I think that this kind of approach can be used also for 
DNF5. You can also try `yum --help` and you will see `usage: yum [options] 
COMMAND`. Please all of those examples requires `yum` package installed.

> 
> I understand that deprecation warning has their own issues, but if you 
> already put some thoughts into that topic, I'd like you to elaborate 
> more then just provide statements like above.

DNF in early versions (1.1) provided a warning when `yum` was called. It was 
nice and transparent way how to send a message about redirection to DNF, but we 
got very strong negative feedback about that, therefore we removed it. I don't 
think we should repeat that approach. Personally I don't feel comfortable with 
education of our users using warnings, because they have value at first 
occurrence but then they are annoying.

> 
> 
> Vít

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 25. 10. 22 v 14:00 Jaroslav Mracek napsal(a):

Are there going to be provided some deprecation warning in current
version of DNF, should some commands or option change in DNF5? I think
this would help prepare users for the changes in advance and possible
make the transition smoother.

Vít



Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):

We will create man page for differences between DNF and DNF5 [WIP].



That is nice, but honestly who reads man pages? And especially who reads 
man pages of SW they are not using (assuming that the manpage will be 
part of DNF5 and not DNF).


I understand that deprecation warning has their own issues, but if you 
already put some thoughts into that topic, I'd like you to elaborate 
more then just provide statements like above.



Vít




Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Hi
> 
> 
> On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:
> 
> 
> This response really doesn't clarify what the end result is supposed to be.
>   Are you planning to maintain a symlink from DNF and Yum to DNF5 after the
> transition is complete or not?
> 
> Rahul

Yes, we have a plan to maintain symlinks to `/user/bin/` + ` dnf` or `microdnf` 
or `yum`.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Rahul Sundaram]

Hi


On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:

>
> DNF team has experience with replacing of YUM in Fedora and RHEL. It give
> us an advantage to not repeat the same mistakes. We already know that
> shipping DNF as YUM was not a good idea.
>

This response really doesn't clarify what the end result is supposed to be.
  Are you planning to maintain a symlink from DNF and Yum to DNF5 after the
transition is complete or not?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Are there going to be provided some deprecation warning in current 
> version of DNF, should some commands or option change in DNF5? I think 
> this would help prepare users for the changes in advance and possible 
> make the transition smoother.
> 
> Vít
> 
> 
> 
> Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):

We will create man page for differences between DNF and DNF5 [WIP].

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):
> 
> 
> So why there is proposed the `/usr/bin/dnf` symlink? To create the 
> confusion again?

For Fedora 38 we cannot ship DNF binary. We also cannot provide dnf, hawkey or 
libdnf in Python bindings, because the those name spaces are already taken by 
DNF, LIBDNF and there is a requirement to keep python3-dnf around (Fedora 39). 
Then we want to unify brand - therefore we do not want to ship product with one 
name, providing different name for bindings and so on. 

 
 
> 
> This ^^ is self-imposed restriction. From practical POV, if DNF5 works 
> and provides all required functionality, there is no need for parallel 
> installability.
> 

Porting to DNF5 API will require some transition period even when all required 
functionality will be in place.

> 
> 
> I am not convinced. Your store is not consistent. On one hand, you want 
> to provide as much compatibility as possible, but on the other hand, you 
> does not hesitate to break the first think you can and that is the name.
> 
> Honestly, if DNF is written in Python or C++ and if there are libraries 
> or bindings or what not is just implementation detail. I understand it 
> matters to you, as a developer. I understand it matters to several other 
> people maintaining some DNF plugins. But it does not matter and should 
> not really matter to end user.
> 
> IOW if we need to update the documentation for DNF in a way that `dnf 
> install --some-option something` does not work DNF5 and `dnf install 
> --new-option something` must be used, that is fine. But if the change 
> was to `dnf5 install --some-option something`, because "we keep the 
> compatibility, the options are the same of course", then this would be 
> ridiculous. Yes, I know "the symlink". But you want to avoid confusion 
> as you said, then why the symlink which will create just confusion.

DNF team has experience with replacing of YUM in Fedora and RHEL. It give us an 
advantage to not repeat the same mistakes. We already know that shipping DNF as 
YUM was not a good idea. There was a lot of confusions therefore in RHEL9 we 
ship DNF as DNF and not YUM. DNF provides great compatibility with YUM but 
anyway it was not the best move that we did. The naming is really tricky and we 
cannot satisfy everyone.

Jaroslav

> 
> 
> Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

I am sorry, `libdnf-devel` and `libdnf5-devel` conflict on file level. We had a 
plan to remove the conflict, but community did not considered it as required, 
therefore we drop that plan. Also the conflict we can take as a feature. The 
code that would use libdnf and libdnf5 at the same time would be a nightmare.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Are there going to be provided some deprecation warning in current 
version of DNF, should some commands or option change in DNF5? I think 
this would help prepare users for the changes in advance and possible 
make the transition smoother.


Vít



Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):

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.



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[José Abílio Matos]

On Monday, 17 October 2022 08.28.11 WEST Jaroslav Mracek wrote:
> Thank you for pointing this. Why DNF5 is not named as DNF and why we do not
> plan to name it as DNF? DNF5 is a completely new product.

That is where the irony is, it is a new product but you still keep the moniker 
DNF in the name (even if just for now). It is a contradictory message. :-)

The funny part, at least for me, is the 5 in the name, that reminds me of 
rpm5. It seems that for package related issues 5 is a cursed number. :-)

Regards,
-- 
José Abílio Matos___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

I believe that problems related to usage of DNF and DNF5 in parallel are 
ecplained in following section - 
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Problems_related_to_using_DNF5_and_DNF_in_parallel_for_software_modification

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> So, coming back to the steps needed for this to happen as discussed in the 
> FESCo ticket, I
> think the first one is to decide how users can start testing dnf5 on
> "expendable" machines.
> 
> The proposal says that dnf5 can be installed in parallel with dnf. I think 
> this
> doesn't highlight what things will be broken, as tools will still use dnf. 
> Also,
> @zbysek asked in the FESCo ticket what data from the RPM database is shared 
> between the
> two, but didn't receive a reply: say, as a user, I install dnf5 in parallel 
> with dnf,
> will I be able to "dnf install foo" and then "dnf5 uninstall foo"?

Thank you for pointing it out. I will provide additional information in both 
Fedora proposals (replacement of DNF 
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Scope and microdnf 
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf#Scope). Using DNF 
and DNF5 in parallel to manage your system is safe. Both packagers will see 
content modification correctly, but they will not have not additional 
information to performed transaction. The situation will be the sile like when 
you do operation using RPM directly.

> 
> For those two things I wrote above, if in the end dnf5 will be renamed back 
> as dnf to be a
> drop in replacement, wouldn't be better to have dnf5 obsolete dnf starting 
> from now? I
> don't think anyone is going to test it on a production machine anyway...
> 
> Mattia

There is no plan to rename DNF5 to DNF. Our team already shipped YUM as DNF and 
we discovered that it is not good idea. DNF5 upstream is not going to repeat 
the same mistake.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Il 12/10/22 12:28, Vít Ondruch ha scritto:
> My guess is that dnf5 is an entirely different beast than dnf. dnf was
> written in python, dnf5 is written in C (?), so it's not just a major
> version upgrade.
> 
> Mattia

It is correct, DNF5 is a different product written in C++.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Sandro]

On 17-10-2022 09:28, Jaroslav Mracek wrote:

* Naming unification of DNF5 stack - it will be quite strange to name
something dnf that cannot provide dnf and so on.


So RUM it is then: Re-invented Update Manager.

Re-invented like the wheel and should suit all consuming parties. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):

Thank you for pointing this. Why DNF5 is not named as DNF and why we do not 
plan to name it as DNF?
DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the 
same type of work like dnf, microdnf but behavior, internals, and plugins 
differents. If we will name DNF as DNF5 we will create a confusion for users. 
From our point of view it is much better to say that DNF5 is a new product with 
compatibility to DNF than it is enhanced DNF.
It is quite the same what happened with replacement of yum by DNF. In some 
distribution DNF was shipped as YUM in version 4 and it created a lot of 
confusions.



So why there is proposed the `/usr/bin/dnf` symlink? To create the 
confusion again?




On the other side we want to use DNF trademark, because it inherits a lot but 
still DNF5 is not the same as DNF.
With the naming of out stack we have a lot of restriction and I will try to 
mention some of them:
  * DNF5 cannot be named as DNF because there is requirement of parallel 
installability in Fedora 38.



This ^^ is self-imposed restriction. From practical POV, if DNF5 works 
and provides all required functionality, there is no need for parallel 
installability.




  * Python import of DNF5 cannot be shipped as DNF because we need to support 
parallel installability of Python bindings of DNF and DNF5 (same for libdnf and 
libdnf5 python pindings).
  * Naming unification of DNF5 stack - it will be quite strange to name 
something dnf that cannot provide dnf and so on.



I am not convinced. Your store is not consistent. On one hand, you want 
to provide as much compatibility as possible, but on the other hand, you 
does not hesitate to break the first think you can and that is the name.


Honestly, if DNF is written in Python or C++ and if there are libraries 
or bindings or what not is just implementation detail. I understand it 
matters to you, as a developer. I understand it matters to several other 
people maintaining some DNF plugins. But it does not matter and should 
not really matter to end user.


IOW if we need to update the documentation for DNF in a way that `dnf 
install --some-option something` does not work DNF5 and `dnf install 
--new-option something` must be used, that is fine. But if the change 
was to `dnf5 install --some-option something`, because "we keep the 
compatibility, the options are the same of course", then this would be 
ridiculous. Yes, I know "the symlink". But you want to avoid confusion 
as you said, then why the symlink which will create just confusion.



Vít





Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

I am sorry, DNF and DNF5 is not a Fedora packager. DNF and DNF5 is an upstream 
project shipped to Fedora and other distributions including OpenSuse.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Thank you for pointing this. Why DNF5 is not named as DNF and why we do not 
plan to name it as DNF?
DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the 
same type of work like dnf, microdnf but behavior, internals, and plugins 
differents. If we will name DNF as DNF5 we will create a confusion for users. 
From our point of view it is much better to say that DNF5 is a new product with 
compatibility to DNF than it is enhanced DNF.
It is quite the same what happened with replacement of yum by DNF. In some 
distribution DNF was shipped as YUM in version 4 and it created a lot of 
confusions.
On the other side we want to use DNF trademark, because it inherits a lot but 
still DNF5 is not the same as DNF.
With the naming of out stack we have a lot of restriction and I will try to 
mention some of them:
 * DNF5 cannot be named as DNF because there is requirement of parallel 
installability in Fedora 38.
 * Python import of DNF5 cannot be shipped as DNF because we need to support 
parallel installability of Python bindings of DNF and DNF5 (same for libdnf and 
libdnf5 python pindings).
 * Naming unification of DNF5 stack - it will be quite strange to name 
something dnf that cannot provide dnf and so on.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Sorry for the delay in my reply here. ;( 
> 
> Some questions: 
> 
> 
> no releng ticket? :( 
> 
> releng depends on dnf4 for a LOT of scripts. 
> We will need a lot of help moving those to dnf5 I am sure. 
> A porting guide for the python bindings would be welcome.

In source (header files) we have replace tags that are supposed to help with 
porting.
// @replaces dnf:dnf/base.py:method:Base().install(self, pkg_spec, 
reponame=None, strict=True, forms=None)

Additionally we have a plan to provide Python tutorial to make porting easy. 
Right now, documentation is our priority.


> 
> 
> A document like the yum2dnf man page with every single change would be
> welcome. Also it would be nice if dnf5 accepted things and just warned
> on them... ie '--refresh' or 'list' (use repoquery I guess)...

Good suggestion and we plan to provide such a document

> 
> 
> I see a big one missing: koji
> 
> We also have some applications that might use dnf python bindings
> (bodhi, packages, etc)
> 
> IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora
> as soon as you can, because then you would have a place for people to
> file bugs and iterate on things, but of course thats up to you.

The package review process for DNF5 is close to finish, therefore we expect 
release soon.

> 
> kevin

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Pierre-Yves Chibon]

On Thu, Oct 13, 2022 at 10:36:52AM +0300, Panu Matilainen wrote:
> On 10/12/22 17:47, Stephen Smoogen wrote:
> > 
> > 
> > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  > > wrote:
> > 
> > On 10/12/22 08:59, Stephen Smoogen wrote:
> >  > Maybe call it the Fedora Update Manager 'FUM' ?
> > 
> > Unless we're going to call it RUM when it makes its way into RHEL, that
> > name may not be the best choice :-)
> > 
> > 
> > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> > sure they can go with FUM or RUM (RPM Update Manager)..
> 
> RPM Update Manager, an easily pronouncable and distro agnostic acronym which
> even makes sense. Now that would be a hard sell...

Depends, once the age question is resolved, buying RUM should be fairly straight
forward :-p


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Mattia Verga via devel]

So, coming back to the steps needed for this to happen as discussed in the 
FESCo ticket, I think the first one is to decide how users can start testing 
dnf5 on "expendable" machines.

The proposal says that dnf5 can be installed in parallel with dnf. I think this 
doesn't highlight what things will be broken, as tools will still use dnf. 
Also, @zbysek asked in the FESCo ticket what data from the RPM database is 
shared between the two, but didn't receive a reply: say, as a user, I install 
dnf5 in parallel with dnf, will I be able to "dnf install foo" and then "dnf5 
uninstall foo"?

For those two things I wrote above, if in the end dnf5 will be renamed back as 
dnf to be a drop in replacement, wouldn't be better to have dnf5 obsolete dnf 
starting from now? I don't think anyone is going to test it on a production 
machine anyway...

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Heh, I would really prefer to stay with "dnf", but thx everybody for 
brainstorming the name. I like the proposals ;)



Vít


Dne 12. 10. 22 v 15:59 Stephen Smoogen napsal(a):



On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý  wrote:

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
> So since I don't think the DNF5 name and especially the package
name was elaborated here and my wish in package review
> to have the package name just `dnf` was completely ignored [1],
I'll ask here.
>
> Why `dnf5` and not `dnf` version 5. If it is not DNF and it
needs different name, then please rather name it `foobar`.
> I think that introducing the version into name is wrong (with
exception of compat packages) and I think that DNF
> should lead by example and not abusing the package name for version.

My opinion is that it should not be packaged as "dnf" until it is
ready to fully replace DNFv4. And that will take some
time. I think it is fine to introduce it now in Fedora as "dnf5"
package. And later rename it to "dnf".


Maybe call it the Fedora Update Manager 'FUM' ?

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue



--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard 
battle. -- Ian MacClaren


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

Dne 12. 10. 22 v 15:48 Miroslav Suchý napsal(a):

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name 
was elaborated here and my wish in package review to have the package 
name just `dnf` was completely ignored [1], I'll ask here.


Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs 
different name, then please rather name it `foobar`. I think that 
introducing the version into name is wrong (with exception of compat 
packages) and I think that DNF should lead by example and not abusing 
the package name for version.


My opinion is that it should not be packaged as "dnf" until it is 
ready to fully replace DNFv4. And that will take some time. I think it 
is fine to introduce it now in Fedora as "dnf5" package. And later 
rename it to "dnf".



There are following statements in the "Scope" section of current change 
proposal:


* Obsolete dnf package by dnf5

* Modify comps groups to replace dnf or yum by dnf5

This does not suggest that "And later rename it to "dnf"." is the plan.

But if it is the plan, then I'd love to see it documented in the change 
proposal. Of course the rename back to "dnf" should happen prior various 
places and especially documentation gets updated to "dnf5".




Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Panu Matilainen]

On 10/12/22 17:47, Stephen Smoogen wrote:



On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming > wrote:


On 10/12/22 08:59, Stephen Smoogen wrote:
 > Maybe call it the Fedora Update Manager 'FUM' ?

Unless we're going to call it RUM when it makes its way into RHEL, that
name may not be the best choice :-)


Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am 
sure they can go with FUM or RUM (RPM Update Manager).. 


RPM Update Manager, an easily pronouncable and distro agnostic acronym 
which even makes sense. Now that would be a hard sell...


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Sandro]

On 12-10-2022 17:19, Neal Gompa wrote:
On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin 
 wrote:


On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen
 wrote:

On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming
 wrote:

On 10/12/22 08:59, Stephen Smoogen wrote:

Maybe call it the Fedora Update Manager 'FUM' ?


Unless we're going to call it RUM when it makes its way into
RHEL, that name may not be the best choice :-)


I like RUM. Goes well with RPM. But I'd probably symlink it to whisky.

In honor of Seth Vidal, I would also support going back to YUM.

How about YUMMER? Referring back to YUM and making all Dutch speaking 
users giggle.



Well Red Hat shipped the Yellowdog Update Manager for 2 releases
so I am sure they can go with FUM or RUM (RPM Update Manager).. I
would avoid Backup Upgrade Manager though.


Ugh, acronyms, how boring. If we stay true to the abbreviation
equilibristics that gave us DNF coming from DaNdiFied YUM, it's
only natural to name the ApPoinTed DNF successor APT. =)


I think Julian Klode would kill us for that. :P


How about yapt? Putting yum into apt or making apt yummie. :D

On 12-10-2022 17:20, Jonathan Wright via devel wrote:

Think about all the guides that can be found via search engines for how to
do things in a given OS.  If we're constantly changing the package
manager/command, even if syntax is similar or identical, it's raising the
bar of entry for inexperienced users.


All solvable by providing symlinks as is currently the case for yum. I 
still happen to type 'yum install' on a regular basis. As the saying 
goes: You cannot teach an old (yellow) dog new tricks.


-- Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Miroslav Suchý]

Dne 12. 10. 22 v 17:02 Mattia Verga via devel napsal(a):

My guess is that dnf5 is an entirely different beast than dnf. dnf was
written in python, dnf5 is written in C (?), so it's not just a major
version upgrade.


It is different beast for developers and author of plugins. Otherwise 1) it has configs on the same place 2) the configs 
values are the same 3) the command line options are almost the same.


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Chuck Anderson]

On Wed, Oct 12, 2022 at 10:47:07AM -0400, Stephen Smoogen wrote:
> On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  wrote:
> 
> > On 10/12/22 08:59, Stephen Smoogen wrote:
> > > Maybe call it the Fedora Update Manager 'FUM' ?
> >
> > Unless we're going to call it RUM when it makes its way into RHEL, that
> > name may not be the best choice :-)
> >
> >
> Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> sure they can go with FUM or RUM (RPM Update Manager).. I would avoid
> Backup Upgrade Manager though.

How about PUM, Package Update Manager?  Pa rum pum pum pum...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jonathan Wright via devel]

Constantly changing the name/command of the package manager seems like a
huge annoyance to end users at best, and a point of discouragement at worst.

Think about all the guides that can be found via search engines for how to
do things in a given OS.  If we're constantly changing the package
manager/command, even if syntax is similar or identical, it's raising the
bar of entry for inexperienced users.

For this reason I think it makes far more sense to let "dnf5" eventually
just become "dnf" even if that means some features/flags are simply dropped.

On Wed, Oct 12, 2022 at 10:15 AM Alexander Sosedkin 
wrote:

> On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen 
> wrote:
> > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming 
> wrote:
> >> On 10/12/22 08:59, Stephen Smoogen wrote:
> >> > Maybe call it the Fedora Update Manager 'FUM' ?
> >>
> >> Unless we're going to call it RUM when it makes its way into RHEL, that
> >> name may not be the best choice :-)
> >
> > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
> sure they can go with FUM or RUM (RPM Update Manager).. I would avoid
> Backup Upgrade Manager though.
>
> Ugh, acronyms, how boring.
> If we stay true to the abbreviation equilibristics
> that gave us DNF coming from DaNdiFied YUM,
> it's only natural to name the ApPoinTed DNF successor APT. =)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Neal Gompa]

On Wed, Oct 12, 2022 at 11:15 AM Alexander Sosedkin
 wrote:
>
> On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen  wrote:
> > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  wrote:
> >> On 10/12/22 08:59, Stephen Smoogen wrote:
> >> > Maybe call it the Fedora Update Manager 'FUM' ?
> >>
> >> Unless we're going to call it RUM when it makes its way into RHEL, that
> >> name may not be the best choice :-)
> >
> > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am 
> > sure they can go with FUM or RUM (RPM Update Manager).. I would avoid 
> > Backup Upgrade Manager though.
>
> Ugh, acronyms, how boring.
> If we stay true to the abbreviation equilibristics
> that gave us DNF coming from DaNdiFied YUM,
> it's only natural to name the ApPoinTed DNF successor APT. =)

I think Julian Klode would kill us for that. :P



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Alexander Sosedkin]

On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen  wrote:
> On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  wrote:
>> On 10/12/22 08:59, Stephen Smoogen wrote:
>> > Maybe call it the Fedora Update Manager 'FUM' ?
>>
>> Unless we're going to call it RUM when it makes its way into RHEL, that
>> name may not be the best choice :-)
>
> Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure 
> they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup 
> Upgrade Manager though.

Ugh, acronyms, how boring.
If we stay true to the abbreviation equilibristics
that gave us DNF coming from DaNdiFied YUM,
it's only natural to name the ApPoinTed DNF successor APT. =)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Mattia Verga via devel]

Il 12/10/22 12:28, Vít Ondruch ha scritto:
> So since I don't think the DNF5 name and especially the package name was
> elaborated here and my wish in package review to have the package name
> just `dnf` was completely ignored [1], I'll ask here.
>
> Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs
> different name, then please rather name it `foobar`. I think that
> introducing the version into name is wrong (with exception of compat
> packages) and I think that DNF should lead by example and not abusing
> the package name for version.
>
>
> Vít
>
>
My guess is that dnf5 is an entirely different beast than dnf. dnf was
written in python, dnf5 is written in C (?), so it's not just a major
version upgrade.

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Neal Gompa]

On Wed, Oct 12, 2022 at 10:31 AM Kevin P. Fleming  wrote:
>
> On 10/12/22 08:59, Stephen Smoogen wrote:
> > Maybe call it the Fedora Update Manager 'FUM' ?
>
> Unless we're going to call it RUM when it makes its way into RHEL, that
> name may not be the best choice :-)
>

Let's not forget all the other distros that now use DNF... This would
be a very poor choice indeed. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Stephen Smoogen]

On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming  wrote:

> On 10/12/22 08:59, Stephen Smoogen wrote:
> > Maybe call it the Fedora Update Manager 'FUM' ?
>
> Unless we're going to call it RUM when it makes its way into RHEL, that
> name may not be the best choice :-)
>
>
Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am
sure they can go with FUM or RUM (RPM Update Manager).. I would avoid
Backup Upgrade Manager though.


> --
> Kevin P. Fleming
> He/Him/His
> Principal Program Manager, RHEL
> Red Hat US/Eastern Time Zone
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kevin P. Fleming]

On 10/12/22 08:59, Stephen Smoogen wrote:

Maybe call it the Fedora Update Manager 'FUM' ?


Unless we're going to call it RUM when it makes its way into RHEL, that 
name may not be the best choice :-)


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Stephen Smoogen]

On Wed, 12 Oct 2022 at 09:49, Miroslav Suchý  wrote:

> Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
> > So since I don't think the DNF5 name and especially the package name was
> elaborated here and my wish in package review
> > to have the package name just `dnf` was completely ignored [1], I'll ask
> here.
> >
> > Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs
> different name, then please rather name it `foobar`.
> > I think that introducing the version into name is wrong (with exception
> of compat packages) and I think that DNF
> > should lead by example and not abusing the package name for version.
>
> My opinion is that it should not be packaged as "dnf" until it is ready to
> fully replace DNFv4. And that will take some
> time. I think it is fine to introduce it now in Fedora as "dnf5" package.
> And later rename it to "dnf".
>
>
Maybe call it the Fedora Update Manager 'FUM' ?



> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Miroslav Suchý]

Dne 12. 10. 22 v 12:28 Vít Ondruch napsal(a):
So since I don't think the DNF5 name and especially the package name was elaborated here and my wish in package review 
to have the package name just `dnf` was completely ignored [1], I'll ask here.


Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs different name, then please rather name it `foobar`. 
I think that introducing the version into name is wrong (with exception of compat packages) and I think that DNF 
should lead by example and not abusing the package name for version.


My opinion is that it should not be packaged as "dnf" until it is ready to fully replace DNFv4. And that will take some 
time. I think it is fine to introduce it now in Fedora as "dnf5" package. And later rename it to "dnf".


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vít Ondruch]

So since I don't think the DNF5 name and especially the package name was 
elaborated here and my wish in package review to have the package name 
just `dnf` was completely ignored [1], I'll ask here.


Why `dnf5` and not `dnf` version 5. If it is not DNF and it needs 
different name, then please rather name it `foobar`. I think that 
introducing the version into name is wrong (with exception of compat 
packages) and I think that DNF should lead by example and not abusing 
the package name for version.



Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2120661#c14


Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):

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/devel@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 

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

python3-dnf is not going to be removed from Fedora 38 or 39. There is even not 
a conflict between dnf5 and python3-dnf. Anyway we strongly recommend to start 
with transition to DNF5.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Brian C. Lane]

On Sat, Sep 24, 2022 at 08:01:45PM -0500, Maxwell G via devel wrote:
> On Tue Sep 6, 2022, Ben Cotton wrote:
> > == 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`.
> 
> I am worried about removing python3-dnf this early. As far as I can
> tell, the new Python libdnf bindings are very much not a drop in
> replacement. There are a fair amount of tools and scripts that depend on
> python3-dnf. The change proposal listed some of them, but Ansible's dnf

I'm worried about replacing it at all. I'd like to see them coexist
until we can get things rewritten, but it also says their databases are
separate which will possibly cause other issues so that's also likely to
lead to different problems.

I took a stab at converting my test-dnf-transaction script yesterday,
and the changes so far are not anywhere near compatible with dnf v4, and
I didn't manage to get it working yet.

https://github.com/bcl/test-dnf-transaction/pull/1

https://github.com/rpm-software-management/dnf5/issues/66

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Maxwell G via devel]

On Sat Sep 24, 2022, Maxwell G wrote:
> On Tue Sep 6, 2022, Ben Cotton wrote:
> > == 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`.
>
> I am worried about removing python3-dnf this early. As far as I can
> tell, the new Python libdnf bindings are very much not a drop in
> replacement. There are a fair amount of tools and scripts that depend on
> python3-dnf. The change proposal listed some of them, but Ansible's dnf
> module is notably missing.

I filed https://github.com/ansible/ansible/issues/78898 about Ansible's
dnf module.

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kevin Fenzi]

Sorry for the delay in my reply here. ;( 

Some questions: 

> * Release engineering: [https://pagure.io/releng/issues #Releng issue number]

no releng ticket? :( 

releng depends on dnf4 for a LOT of scripts. 
We will need a lot of help moving those to dnf5 I am sure. 
A porting guide for the python bindings would be welcome.

> 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.

A document like the yum2dnf man page with every single change would be
welcome. Also it would be nice if dnf5 accepted things and just warned
on them... ie '--refresh' or 'list' (use repoquery I guess)...

> == Dependencies ==
> There is a long list of dependent packages

I see a big one missing: koji

We also have some applications that might use dnf python bindings
(bodhi, packages, etc)

IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora
as soon as you can, because then you would have a place for people to
file bugs and iterate on things, but of course thats up to you. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Maxwell G via devel]

On Tue Sep 6, 2022, Ben Cotton wrote:
> == 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`.

I am worried about removing python3-dnf this early. As far as I can
tell, the new Python libdnf bindings are very much not a drop in
replacement. There are a fair amount of tools and scripts that depend on
python3-dnf. The change proposal listed some of them, but Ansible's dnf
module is notably missing. Personal user scripts (such as the one I use
for Go CVE rebuilds) and some of releng's scripts will also be broken. I
don't think we should proceed with removing python3-dnf until the
majority of the important dependent software is ported. (To be clear, I
don't consider my personal scripts to be important dependent software
:).

In general, I think the "If DNF5 will be not ready to replace DNF"
contingent needs to have definite criteria and the compatibility section
needs to be expanded. Of course FESCo can do as they see fit, but I
personally have qualms with approving a major change like this in
advanced of an actual stable release and major testing, especially
without a clear definition of when DNF5 is considered ready to replace
DNF4.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Ben Cotton kirjoitti 6.9.2022 klo 21.28:
> 
> 
> These two are the only mentions of dnf-automatic in this change. What 
> does "replace" mean here? How does DNF5 cover dnf-automatic's use case?

This is a good question. We will replace the functionality, but it is still on 
our TODO list, therefore I cannot provide details right now.
Jaroslav Mracek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Marius Schwarz]

Am 20.09.22 um 22:53 schrieb Tommy Nguyen:

DNF5 is ridiculously fast. The new text output using the C++ fmt
library is also a bonus.


Yes, it's fast, which is a great improvement \o/ The new output format 
is ... debateable. It has advantages with "screen -x"-sessions with 
different resolutions,
but hardcore dnf fans will need to adapt to it. The old one was a bit 
simplier and had a more eased, not to say relaxed, flair ;)


best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Sandro]

On 21-09-2022 09:33, Sandro wrote:

As of recent, memory usage might be of a larger concern. Of which your
data shows a very welcome 40% reduction. I'll gladly take the speed
improvement as a bonus.


I wrote that before morning coffee. It's a 60% reduction. DNF5 is using 
only 40% of what DNF uses in Tommy's test case.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Sandro]

On 21-09-2022 03:11, Tommy Nguyen wrote:

On Wed, 2022-09-21 at 02:53 +0200, Kevin Kofler via devel wrote:

Tommy Nguyen wrote:

DNF5 is ridiculously fast.


It is faster, but "ridiculously"? In the metric that matters
(elapsed wallclock time), your benchmark shows the update taking
30% less time.

That said, there are other features of DNF5 (no more Python,
shared cache between PackageKit and CLI) that are IMHO even more
interesting than the raw speed gain.


Would you have preferred if I used a different superlative? I still 
consider 30% less to be significant, especially because DNF5

processes metadata in parallel which makes things seem faster,
whether perceived or real. And yes, the other improvements are good
as well, but end users focus on speed. See: constant discussions
about how to make DNF4 faster (including enabling fastestmirror which
can make things slower) or perception that it is slower because it
processes metadata at a different stage than apt for example.


As of recent, memory usage might be of a larger concern. Of which your
data shows a very welcome 40% reduction. I'll gladly take the speed
improvement as a bonus.

Having followed the discussion, the challenging part will be the
adaptation of all dependent packages to DNF5. I'll leave it to others to
coin terms and attributes for the new DNF5.

-- Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Tommy Nguyen]

On Wed, 2022-09-21 at 02:53 +0200, Kevin Kofler via devel wrote:
> Tommy Nguyen wrote:
> > DNF5 is ridiculously fast.
> 
> It is faster, but "ridiculously"? In the metric that matters (elapsed
> wallclock time), your benchmark shows the update taking 30% less
> time.
> 
> That said, there are other features of DNF5 (no more Python, shared
> cache 
> between PackageKit and CLI) that are IMHO even more interesting than
> the raw 
> speed gain.

Would you have preferred if I used a different superlative? I still
consider 30% less to be significant, especially because DNF5 processes
metadata in parallel which makes things seem faster, whether perceived
or real. And yes, the other improvements are good as well, but end
users focus on speed. See: constant discussions about how to make DNF4
faster (including enabling fastestmirror which can make things slower)
or perception that it is slower because it processes metadata at a
different stage than apt for example.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kevin Kofler via devel]

Tommy Nguyen wrote:
> DNF5 is ridiculously fast.

It is faster, but "ridiculously"? In the metric that matters (elapsed 
wallclock time), your benchmark shows the update taking 30% less time.

That said, there are other features of DNF5 (no more Python, shared cache 
between PackageKit and CLI) that are IMHO even more interesting than the raw 
speed gain.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Tommy Nguyen]

For those who are still not convinced, here is a comparison:

$ toolbox create -d fedora -r 37 && toolbox enter
$ sudo time dnf upgrade -y
26.79user 3.46system 0:49.09elapsed 61%CPU (0avgtext+0avgdata
489304maxresident)k
47400inputs+1243320outputs (266major+377843minor)pagefaults 0swaps

$ toolbox create -d fedora -r 37 && toolbox enter
$ sudo dnf copr enable rpmsoftwaremanagement/dnf5-unstable 
$ sudo dnf install dnf5 -y
$ sudo time dnf5 upgrade -y
11.55user 3.40system 0:33.98elapsed 44%CPU (0avgtext+0avgdata
199056maxresident)k
72inputs+1203072outputs (280major+191432minor)pagefaults 0swaps

DNF5 is ridiculously fast. The new text output using the C++ fmt
library is also a bonus.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Otto Liljalaakso]

Ben Cotton kirjoitti 6.9.2022 klo 21.28:

== 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.



== Upgrade/compatibility impact ==
The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
and DNF plugins (core and extras).d by `fedora-obsolete-packages`.


These two are the only mentions of dnf-automatic in this change. What 
does "replace" mean here? How does DNF5 cover dnf-automatic's use case?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Joseph Marrero]

+1 on this, I was wondering if there are any plans to include
rpm-ostree in this effort?

rpm-ostree today uses libdnf and since fedora silverblue & fedora
coreos are managed by rpm-ostree it would be nice to have an unified
plan/coordination for this change.

Furthermore, it would also be nice if we could provide a more unified
user experience in the Fedora distributions universe.

--
Joseph Marrero
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Maxwell G via devel]

Sep 8, 2022 8:45:19 AM Maxwell G via devel 
:



On Thursday, September 8, 2022 Jaroslav Mracek wrote:

First of all we are not going to remove old DNF from the distribution.


Isn't that what


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`.


says?
Sorry, I was unclear. I meant to say that those two statements appear 
contradictory.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Maxwell G via devel]

On Thursday, September 8, 2022 Jaroslav Mracek wrote:
> First of all we are not going to remove old DNF from the distribution.

Isn't that what

> 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`.

says?

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Milan Crha]

On Thu, 2022-09-08 at 08:39 -0400, Nico Kadel-Garcia wrote:
> installing parallel versions of the same development tools

Hi,
Jaroslav said they are not the same, hence I asked.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Nico Kadel-Garcia]

On Thu, Sep 8, 2022 at 8:27 AM Milan Crha  wrote:
>
> On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote:
> > DNF5 is completely a different component. It does not depend like
> > microdnf on Python. DNF plugins are not compatible with DNF5. There
> > will be changes in commands, options, outputs and so on therefore
> > selling it as an update will be quite confusing.
>
> Hi,
> the current COPR builds for early testers conflict on the libdnf5-devel
> package:
>
>   - package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64
> conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0-
> 1.fc37.x86_64
>
> Is that going to be solved anyhow, or it's expected? The
> library/executable files can be installed in parallel, it seems, or at
> least those I tried, but having the devel files for both is not
> possible at the moment. It would be useful to not conflict the files,
> thus one can build on one machine for both versions, not replace the
> devel files constantly, if the two are supposed to live together for
> some time.
> Bye,
> Milan

And I'd like a pony. More seriously, installing parallel versions of
the same development tools overn conflict due to files in
/usr/include/ unless the original others thought to distribute the
software in major version specific subdirectories. Not many utilities
do that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Happy to hear that.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Correct, DNF5 will provide a library - LIBDNF5 that will provide C++ API plus 
bindings to various languages including Python.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Am 06.09.22 um 20:28 schrieb Ben Cotton:
> 
> If it's still written in python, it will still be slow on devices like 
> Pinephones. I was under the impression, that microdnf + libdnf was 
> developed to counter this slowness?
> 
> best regards,
> Marius Schwarz

No, DNF5 is not written in Python. Performance improvements are not based on 
dropping Python, but by better logic in code.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Milan Crha]

On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote:
> DNF5 is completely a different component. It does not depend like
> microdnf on Python. DNF plugins are not compatible with DNF5. There
> will be changes in commands, options, outputs and so on therefore
> selling it as an update will be quite confusing.

Hi,
the current COPR builds for early testers conflict on the libdnf5-devel
package:

  - package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64
conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0-
1.fc37.x86_64

Is that going to be solved anyhow, or it's expected? The
library/executable files can be installed in parallel, it seems, or at
least those I tried, but having the devel files for both is not
possible at the moment. It would be useful to not conflict the files,
thus one can build on one machine for both versions, not replace the
devel files constantly, if the two are supposed to live together for
some time.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer  wrote:
> 
> As a plugin author, I'd like something like this too...
> 
> 
> Porting PackageKit mostly requires some API documentation and examples
> for porting the existing DNF backend code to the new one. Some
> assistance from the DNF team might be needed too.

We work on improving documentation. There ate already tutorials. 
Tutorials: https://libdnf.readthedocs.io/en/dnf-5-devel/tutorial/index.html - 
Recently we rename the project to DNF5 therefore updated documentation is not 
yet available.

Jaroslav

> 
> We can ship a DNF5 backend alongside the DNF4 one in the upstream
> sources and switch backends in Fedora as needed.
> 
> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  
> Is there any analysis on how many yum3/dnf4 plugins exist outside of
> the core set that the DNF team maintains?  I'm curious how much of a
> porting effort is required to move from yum3/dnf4 for plugin authors.

I think as an analyses can be count the list of dependencies mentioned in 
Dependencis section. Specially I focused there packages not maintained by DNF 
team. Plugins that are not in Fedora are difficult to track. The change 
announcement is also the way how to get information about external dependencies.

> 
> Will there be documentation and best practices on migration for plugin
> maintainers?

Yes, we will provide documentation and an example plugin. But we also are 
willing to help with the transition.

> 
> 
> Is this daemon optional depending on installation type, or will it be
> running on all installations?  I am assuming it is optional and
> centered mostly around whatever currently needs PackageKit.

DNF5 runs without a daemon. There are user-cases where daemon cannot be used. 

> 
> 
> Do we have some statistics on the consolidated installation size of
> DNF5 vs. dnf4?

Yes, 
DNF - download size 48 MB, install size 166 MB, 125 Packages
Microdnf - download size 34 MB, install size 115 MB, 101 Packages
Dnf5 with libmodulemd - download size 33 MB, install size 114 MB, 100 Packages

> 
> Any performance comparisons?

Yes, but take them as preliminary:
dnf repoquery $(rpm -qa) - 4.06s
dnf5 repoquery $(rpm -qa) - 1.42s
dnf upgrade $(rpm -qa) --assumeno - 15.77s
dnf5 upgrade $(rpm -qa) --assumeno - 2.57s

Jaroslav

> 
> josh
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

Such a user-case should be covered by DNF5 compatibility with DNF and maybe 
there will be not a requirement for any change in your code. There are changes 
in DNF5 but only when it provides a benefit and resolve some issues.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

It is true, we need a cooperation with maintainers of many components, but not 
everything on the list is critical for transition or proposal itself. First of 
all we are not going to remove old DNF from the distribution. Then only DNF and 
DNF5 directly conflict therefore there is some room for an extension of 
transition period, but it depends on particular component. Components that 
installs content on the system has higher priority for transition then other 
use-cases with DNF.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

DNF5 is completely a different component. It does not depend like microdnf on 
Python. DNF plugins are not compatible with DNF5. There will be changes in 
commands, options, outputs and so on therefore selling it as an update will be 
quite confusing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Tommy Nguyen]

On Thu, 2022-09-08 at 10:13 +0200, Marius Schwarz wrote:
> If it's still written in python, it will still be slow on devices
> like 
> Pinephones. I was under the impression, that microdnf + libdnf was 
> developed to counter this slowness?
> 
> best regards,
> Marius Schwarz

Though I don't know how it'll perform on an embedded device, I tested
it in toolbox and it's MUCH faster than dnf 4.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Fabio Alessandro Locati]

On Thu, Sep 8, 2022, at 10:13, Marius Schwarz wrote:
> Am 06.09.22 um 20:28 schrieb Ben Cotton:
>> * Unify Python bindings
>
> If it's still written in python, it will still be slow on devices like 
> Pinephones. I was under the impression, that microdnf + libdnf was 
> developed to counter this slowness?

My understanding is that dnf is written 100% in Python [0], while libdnf is 
written in C [1], dnf5 is written in C++ [2]. Though, to guarantee 
compatibility, dnf5 will have Python bindings  to allow Python software to 
easily use dnf5 (as well as bindings for other languages such as Perl and Ruby).

[0] https://github.com/rpm-software-management/dnf
[1] https://github.com/rpm-software-management/microdnf
[2] https://github.com/rpm-software-management/dnf5
-- 
Fabio Alessandro "Fale" Locati
fale.io
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Marius Schwarz]

Am 06.09.22 um 20:28 schrieb Ben Cotton:

* 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


If it's still written in python, it will still be slow on devices like 
Pinephones. I was under the impression, that microdnf + libdnf was 
developed to counter this slowness?


best regards,
Marius Schwarz

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Neal Gompa]

On Wed, Sep 7, 2022 at 3:17 PM Josh Boyer  wrote:
>
> On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:
> >
> > 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/devel@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
>
> Is there any analysis on how many yum3/dnf4 plugins exist outside of
> the core set that the DNF team maintains?  I'm curious how much of a
> porting effort is required to move from yum3/dnf4 for plugin authors.
>
> Will there be documentation and best practices on migration for plugin
> maintainers?
>

As a plugin author, I'd like something like this too...

> > ** 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
>
> Is this daemon optional depending on installation type, or will it be
> running on all installations?  I am assuming it is optional and
> centered mostly around whatever currently needs PackageKit.
>

Porting PackageKit mostly requires some API documentation and examples
for porting the existing DNF backend code to the new one. Some
assistance from the DNF team might be needed too.

We can ship a DNF5 backend alongside the DNF4 one in the upstream
sources and switch backends in Fedora as needed.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Josh Boyer]

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:
>
> 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/devel@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

Is there any analysis on how many yum3/dnf4 plugins exist outside of
the core set that the DNF team maintains?  I'm curious how much of a
porting effort is required to move from yum3/dnf4 for plugin authors.

Will there be documentation and best practices on migration for plugin
maintainers?

> ** 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

Is this daemon optional depending on installation type, or will it be
running on all installations?  I am assuming it is optional and
centered mostly around whatever currently needs PackageKit.

> ** 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

Do we have some statistics on the consolidated installation size of
DNF5 vs. dnf4?

Any performance comparisons?

josh

> * 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 

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Richard W.M. Jones]

On Tue, Sep 06, 2022 at 02:28:41PM -0400, Ben Cotton wrote:
>  supermin

Supermin requires only that:

  dnf download --destdir= [list of pkgs] [-c configfile]

works *as non-root* (or some equivalent of that command as non-root)
to download the RPMs.  Does dnf5 support that?  Note it's especially
important that it does not require special privileges.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Adam Williamson]

On Tue, 2022-09-06 at 14:28 -0400, Ben Cotton wrote:
> 
> == 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]

[snip]

> == 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

So, I feel like it's an issue that we have this huge list of
dependencies of the current implementation, but up there under "Other
developers:" in the Scope section, there is nothing.

The list of dependencies implies a fairly considerable amount of work
is going to be necessary on the part of "other developers" to adapt all
of these dependencies to dnf5. A lot of those dependencies are very
important - they are core components of how we work on, build, and use
Fedora.

I think this Change needs explicit buy-in from the maintainers of
dependent packages, and a clear plan and timeline for how those
packages will be ported to dnf5 such that the Change can land smoothly
in F39 timeframe.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 06/09/2022 20:28, Ben Cotton wrote:

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.


Why not just update existing dnf packages to version 5?

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Ben Cotton]

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 

F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Ben Cotton]

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/devel@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