12:42 a.m.
Hello everyone,
We've prepared a side-tag for testing Rawhide with dnf5 as the default
package manager. Instructions for installing the packages from the side-tag
can be found at the following link [1].
Please provide feedback in Bodhi or on this mailing list regarding the use
cases you're familiar with from the existing dnf command, and share your
experience with this new version.
If there's no negative feedback regarding any critical functionality, we
plan to push the packages from the side-tag to Rawhide next week.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
Thanks,
Jan
12:56 a.m.
On Thu, 2024-04-25 at 07:42 +0200, Jan Kolarik wrote:
Hello everyone,
We've prepared a side-tag for testing Rawhide with dnf5 as the default
package manager. Instructions for installing the packages from the side-tag
can be found at the following link [1].
Please provide feedback in Bodhi or on this mailing list regarding the use
cases you're familiar with from the existing dnf command, and share your
experience with this new version.
If there's no negative feedback regarding any critical functionality, we
plan to push the packages from the side-tag to Rawhide next week.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
The update failed a couple of openQA tests. I will take a closer look
into the reason in the morning, I'm busy reneedling things for the GTK
update at present.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1:19 p.m.
On Wed, 2024-04-24 at 22:56 -0700, Adam Williamson wrote:
On Thu, 2024-04-25 at 07:42 +0200, Jan Kolarik wrote:
> Hello everyone,
>
> We've prepared a side-tag for testing Rawhide with dnf5 as the default
> package manager. Instructions for installing the packages from the side-tag
> can be found at the following link [1].
>
> Please provide feedback in Bodhi or on this mailing list regarding the use
> cases you're familiar with from the existing dnf command, and share your
> experience with this new version.
>
> If there's no negative feedback regarding any critical functionality, we
> plan to push the packages from the side-tag to Rawhide next week.
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
The update failed a couple of openQA tests. I will take a closer look
into the reason in the morning, I'm busy reneedling things for the GTK
update at present.
Just to follow up on this: the Kiwi container build test failure
pointed to some changes that will be required to the Fedora kiwi config
when this change lands. I have filed a PR for that -
https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which
should only be merged when this update is getting pushed. I tweaked the
openQA test to make those changes on-the-fly when testing this update,
and now it passes.
By inference it occurred to me to check the osbuild configs also and I
found a likely-required change there, so I sent a PR for that -
https://github.com/osbuild/images/pull/637 - which has been merged. We
would need the osbuild folks to deploy that change to prod before this
update lands in Rawhide, otherwise some osbuild-driven image builds
will most likely start to fail.
The Cockpit update test failures turned out to be just stricter
defaults in the new dnf exposing a bug in how the openQA tests handle
the advisory repo (the side repo that contains the packages from the
update under testing). I fixed that, and now the tests pass.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8:46 a.m.
Hi Adam,
Just to follow up on this: the Kiwi container build test failure
pointed to some changes that will be required to the Fedora kiwi config
when this change lands. I have filed a PR for that -
https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which
should only be merged when this update is getting pushed. I tweaked the
openQA test to make those changes on-the-fly when testing this update,
and now it passes.
By inference it occurred to me to check the osbuild configs also and I
found a likely-required change there, so I sent a PR for that -
https://github.com/osbuild/images/pull/637 - which has been merged. We
would need the osbuild folks to deploy that change to prod before this
update lands in Rawhide, otherwise some osbuild-driven image builds
will most likely start to fail.
Oh, great! We were planning to handle these ourselves, so thanks a lot for
help!
The Cockpit update test failures turned out to be just stricter
defaults in the new dnf exposing a bug in how the openQA tests handle
the advisory repo (the side repo that contains the packages from the
update under testing). I fixed that, and now the tests pass.
Great, thanks!
Regards,
Jan
On Fri, Apr 26, 2024 at 8:20 PM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
> On Wed, 2024-04-24 at 22:56 -0700, Adam Williamson wrote:
> > On Thu, 2024-04-25 at 07:42 +0200, Jan Kolarik wrote:
> > > Hello everyone,
> > >
> > > We've prepared a side-tag for testing Rawhide with dnf5 as the default
> > > package manager. Instructions for installing the packages from the
> side-tag
> > > can be found at the following link [1].
> > >
> > > Please provide feedback in Bodhi or on this mailing list regarding the
> use
> > > cases you're familiar with from the existing dnf command, and share
> your
> > > experience with this new version.
> > >
> > > If there's no negative feedback regarding any critical functionality,
> we
> > > plan to push the packages from the side-tag to Rawhide next week.
> > >
> > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
> >
> > The update failed a couple of openQA tests. I will take a closer look
> > into the reason in the morning, I'm busy reneedling things for the GTK
> > update at present.
>
Just to follow up on this: the Kiwi container build test failure
pointed to some changes that will be required to the Fedora kiwi config
when this change lands. I have filed a PR for that -
https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which
should only be merged when this update is getting pushed. I tweaked the
openQA test to make those changes on-the-fly when testing this update,
and now it passes.
By inference it occurred to me to check the osbuild configs also and I
found a likely-required change there, so I sent a PR for that -
https://github.com/osbuild/images/pull/637 - which has been merged. We
would need the osbuild folks to deploy that change to prod before this
update lands in Rawhide, otherwise some osbuild-driven image builds
will most likely start to fail.
> The Cockpit update test failures turned out to be just stricter
> defaults in the new dnf exposing a bug in how the openQA tests handle
> the advisory repo (the side repo that contains the packages from the
> update under testing). I fixed that, and now the tests pass.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
> https://www.happyassassin.net
>
>
>
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
>
3:09 a.m.
Il 25/04/24 07:42, Jan Kolarik ha scritto:
Hello everyone,
We've prepared a side-tag for testing Rawhide with dnf5 as the default
package manager. Instructions for installing the packages from the
side-tag can be found at the following link [1].
Please provide feedback in Bodhi or on this mailing list regarding the
use cases you're familiar with from the existing dnf command, and
share your experience with this new version.
If there's no negative feedback regarding any critical functionality,
we plan to push the packages from the side-tag to Rawhide next week.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
Thanks,
Jan
I'd also like to test it on a real F40 machine (I have been using mostly
dnf5 commands in a F40 VM without issues during the latest months), is
there maybe a COPR repo or something like which allows that?
Mattia
4:25 a.m.
Hi Mattia,
Yep, there's a dnf5-testing COPR that serves exactly this purpose:
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing.
Jan
On Thu, Apr 25, 2024 at 10:10 AM Mattia Verga via devel <
devel(a)lists.fedoraproject.org> wrote:
Il 25/04/24 07:42, Jan Kolarik ha scritto:
> Hello everyone,
>
> We've prepared a side-tag for testing Rawhide with dnf5 as the default
> package manager. Instructions for installing the packages from the
> side-tag can be found at the following link [1].
>
> Please provide feedback in Bodhi or on this mailing list regarding the
> use cases you're familiar with from the existing dnf command, and
> share your experience with this new version.
>
> If there's no negative feedback regarding any critical functionality,
> we plan to push the packages from the side-tag to Rawhide next week.
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
>
> Thanks,
> Jan
I'd also like to test it on a real F40 machine (I have been using mostly
dnf5 commands in a F40 VM without issues during the latest months), is
there maybe a COPR repo or something like which allows that?
Mattia
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
3:22 a.m.
Jan Kolarik venit, vidit, dixit 2024-04-25 07:42:10:
Hello everyone,
We've prepared a side-tag for testing Rawhide with dnf5 as the default
package manager. Instructions for installing the packages from the side-tag
can be found at the following link [1].
Please provide feedback in Bodhi or on this mailing list regarding the use
cases you're familiar with from the existing dnf command, and share your
experience with this new version.
If there's no negative feedback regarding any critical functionality, we
plan to push the packages from the side-tag to Rawhide next week.
Does this mean that distro-upgrade from F41 to F42 is supposed to work
at F41 release time (ideally at beta time)?
I'm all for dnf5 and would use it now (and hat an epsisode on F39), but
since distro-ugrades F40->F41 are off the table (as has been stated)
it's not a good idea to use it in F40 unless you are willing to deal
with autoremove trouble and the like.
So, if we push dnf5 as default to rawhide now we have to be reasonably
sure that F41 will distro-ugrade to F42 using dnf5.
Michael
4:42 a.m.
Hello Michael,
Does this mean that distro-upgrade from F41 to F42 is supposed to work
at F41 release time (ideally at beta time)?
Yes, the system-upgrade functionality should be available before the Fedora
41
release date. We're planning extensive testing for this, including a Fedora
Testing Day.
While our goal is to deliver the final system-upgrade functionality before
the stable release,
some adjustments may be made during the Fedora 41 lifecycle to ensure
smoother
upgrades from F41 to F42. Before executing the system-upgrade, users are
anyway
advised to ensure that all installed packages are fully updated.
Jan
On Thu, Apr 25, 2024 at 10:22 AM Michael J Gruber <mjg(a)fedoraproject.org>
wrote:
> Jan Kolarik venit, vidit, dixit 2024-04-25 07:42:10:
> > Hello everyone,
> >
> > We've prepared a side-tag for testing Rawhide with dnf5 as the default
> > package manager. Instructions for installing the packages from the
> side-tag
> > can be found at the following link [1].
> >
> > Please provide feedback in Bodhi or on this mailing list regarding the
> use
> > cases you're familiar with from the existing dnf command, and share your
> > experience with this new version.
> >
> > If there's no negative feedback regarding any critical functionality, we
> > plan to push the packages from the side-tag to Rawhide next week.
>
> Does this mean that distro-upgrade from F41 to F42 is supposed to work
at F41 release time (ideally at beta time)?
> I'm all for dnf5 and would use it now (and hat an epsisode on F39), but
> since distro-ugrades F40->F41 are off the table (as has been stated)
> it's not a good idea to use it in F40 unless you are willing to deal
> with autoremove trouble and the like.
>
> So, if we push dnf5 as default to rawhide now we have to be reasonably
> sure that F41 will distro-ugrade to F42 using dnf5.
>
> Michael
>
>
12:55 p.m.
On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote:
Hello Michael,
Does this mean that distro-upgrade from F41 to F42 is supposed to work
> at F41 release time (ideally at beta time)?
>
Yes, the system-upgrade functionality should be available before the Fedora
41
release date. We're planning extensive testing for this, including a Fedora
Testing Day.
Personally, I think this is a beta requirement.
Lots of people upgrade around then to get on the new release, and also
having it available to test then is pretty important.
Thats just my opinon... QE might have different opinions.
While our goal is to deliver the final system-upgrade functionality
before
the stable release,
some adjustments may be made during the Fedora 41 lifecycle to ensure
smoother
upgrades from F41 to F42. Before executing the system-upgrade, users are
anyway
advised to ensure that all installed packages are fully updated.
So, how do you rate the chances of having something ready by beta
freeze?
kevin
1:56 a.m.
Hi Kevin,
Personally, I think this is a beta requirement.
IIUC the Fedora 41 Beta requirement is to successfully upgrade the system
from Fedora 40, as mentioned here:
https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation.
So this still relates to the dnf4 package, which is used in Fedora 40. I
expect this will become relevant for dnf5 at the Fedora 42 Beta.
So, how do you rate the chances of having something ready by beta
> freeze?
Talking about "something", there's already a system-upgrade command
available in this dnf5 version from the side-tag :) However, as I mentioned
earlier, it hasn't been thoroughly tested yet; that's our goal for the
upcoming months.
Regards,
Jan
On Thu, Apr 25, 2024 at 7:55 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote:
> > Hello Michael,
> > > Does this mean that distro-upgrade from F41 to F42 is
supposed to work
> > > at F41 release time (ideally at beta time)?
> > > > >
Yes, the system-upgrade functionality should be available before the
> Fedora
> > 41
> > release date. We're planning extensive testing for this, including a
> Fedora
> > Testing Day.
> Personally, I think this is a beta requirement.
> Lots of people upgrade around then to get on the new
release, and also
> having it available to test then is pretty important.
> Thats just my opinon... QE might have different opinions.
> > While our goal is to deliver the final system-upgrade
functionality
> before
> > the stable release,
> > some adjustments may be made during the Fedora 41 lifecycle to ensure
> > smoother
> > upgrades from F41 to F42. Before executing the system-upgrade, users are
> > anyway
> > advised to ensure that all installed packages are fully updated.
> So, how do you rate the chances of having something ready
by beta
> freeze?
> kevin
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
3:49 a.m.
Jan Kolarik venit, vidit, dixit 2024-04-26 08:56:48:
Hi Kevin,
Personally, I think this is a beta requirement.
>
IIUC the Fedora 41 Beta requirement is to successfully upgrade the system
from Fedora 40, as mentioned here:
https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation.
So this still relates to the dnf4 package, which is used in Fedora 40. I
expect this will become relevant for dnf5 at the Fedora 42 Beta.
So, how do you rate the chances of having something ready by beta
> freeze?
>
Talking about "something", there's already a system-upgrade command
available in this dnf5 version from the side-tag :) However, as I mentioned
earlier, it hasn't been thoroughly tested yet; that's our goal for the
upcoming months.
Hi folks,
I'm afraid I added to the confusion via a typo. I wondered specifically
about the update F41->F42 because F40->F41 seemed to be off the table:
On Thu, Apr 25, 2024 at 7:55 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote:
> > Hello Michael,
> >
> > Does this mean that distro-upgrade from F41 to F42 is supposed to work
> > > at F41 release time (ideally at beta time)?
No typo in "F41 to F42", but this functionality needs to be ready by F42 (!)
release time, ideally at beta time, so that it can be used and tested.
If we consider "dnf5 distro-upgrade" to be a feature then it has to be there
by F41 feature freeze time actually. And that is why - if dnf5 as
default comes to rawhide now, which is leading up to F41 - we have to be
reasonably sure that the distro-upgrade feature will be ready in time
for the next (F41) feature freeze.
Michael
1:16 p.m.
On Fri, 2024-04-26 at 08:56 +0200, Jan Kolarik wrote:
Hi Kevin,
Personally, I think this is a beta requirement.
>
IIUC the Fedora 41 Beta requirement is to successfully upgrade the system
from Fedora 40, as mentioned here:
https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation.
So this still relates to the dnf4 package, which is used in Fedora 40. I
expect this will become relevant for dnf5 at the Fedora 42 Beta.
Yup, that makes sense to me. The upgrade is all run by the previous
release's DNF, not the new release's DNF.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
1:52 p.m.
On Fri, Apr 26, 2024 at 11:16:28AM GMT, Adam Williamson wrote:
On Fri, 2024-04-26 at 08:56 +0200, Jan Kolarik wrote:
> Hi Kevin,
>
> Personally, I think this is a beta requirement.
> >
>
> IIUC the Fedora 41 Beta requirement is to successfully upgrade the system
> from Fedora 40, as mentioned here:
> https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation.
> So this still relates to the dnf4 package, which is used in Fedora 40. I
> expect this will become relevant for dnf5 at the Fedora 42 Beta.
Yup, that makes sense to me. The upgrade is all run by the previous
release's DNF, not the new release's DNF.
Yeah, sorry... I agree, I was confused. :)
kevin
1:13 p.m.
On Thu, Apr 25, 2024 at 11:42:57AM +0200, Jan Kolarik wrote:
upgrades from F41 to F42. Before executing the system-upgrade, users
are
anyway advised to ensure that all installed packages are fully updated.
I don't believe GNOME Software enforces this. (There was some debate about
whether doing two updates in a row was really useful, if I remember.) That
may be a big source of pain.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:34 p.m.
On Thu, May 2, 2024 at 6:14 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
I don't believe GNOME Software enforces this. (There was some
debate about
whether doing two updates in a row was really useful, if I remember.) That
may be a big source of pain.
As I recall, *much* of the time it does not matter, but
if someone has not kept up with updates the upgrade
programs themselves might be too old to properly
complete the update (such as if dnf-command(system-upgrade)
or rpm needed to be updated). In some previous
versions a blocker for release did require that fixes
be made available for previous versions for successful
updates. While I follow the philosophy of updating
regularly, there are likely some who install Fnn, and
never update, and then would expect an update to
Fnn+2 to work without issue(s).
2:41 p.m.
On 5/2/24 14:34, Gary Buhrmaster wrote:
While I follow the philosophy of updating
regularly, there are likely some who install Fnn, and
never update, and then would expect an update to
Fnn+2 to work without issue(s).
--
The CLI update strongly suggests doing 'dnf update --refresh' before
system-upgrade. It doesn't require it though.
I always thought it's an odd workflow; why doesn't it just force it?
While it might take a long while to complete on a stale system, it's
recommended anyway, isn't it?
On an updated system it's fairly quick turnaround; I usually lose more
time by sitting with an unanswered, unnoticed prompt.
3:28 p.m.
On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote:
On 5/2/24 14:34, Gary Buhrmaster wrote:
> While I follow the philosophy of updating
> regularly, there are likely some who install Fnn, and
> never update, and then would expect an update to
> Fnn+2 to work without issue(s).
> --
The CLI update strongly suggests doing 'dnf update --refresh' before
system-upgrade. It doesn't require it though.
I always thought it's an odd workflow; why doesn't it just force it?
While it might take a long while to complete on a stale system, it's
recommended anyway, isn't it?
I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
2:32 p.m.
On 5/2/24 16:28, Adam Williamson wrote:
On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel
wrote:
> On 5/2/24 14:34, Gary Buhrmaster wrote:
>> While I follow the philosophy of updating
>> regularly, there are likely some who install Fnn, and
>> never update, and then would expect an update to
>> Fnn+2 to work without issue(s).
>> --
> The CLI update strongly suggests doing 'dnf update --refresh' before
> system-upgrade. It doesn't require it though.
>
> I always thought it's an odd workflow; why doesn't it just force it?
> While it might take a long while to complete on a stale system, it's
> recommended anyway, isn't it?
I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.
Even though my personal feet are unscathed by great many online
upgrades, I agree it's a low-probability but high-potential-for-damage
event. Having said that, in the case of system upgrade, a lot of
problems of online upgrades (IPC and ABI incompatibilities, etc) are
not very relevant---the system will instantly reboot for the upgrade, right?
The bottom line is I am old-school and hate rebooting and the associated
loss of 'state', but OTOH most important user-oriented applications save
and restore state already. It's just feels inelegant and ad-hoc, but
may be the price of progress.
I wonder if this means that ostree / CoreOS / Silverblue are the only
way out of this conundrum.
10:54 a.m.
AdamI believe in the KISS principle. Do a simplification change that does it for the
great number of new Fedora users who are coming from other desktop/laptop/business
systems. Linux is gaining #users.
Let us make their migration to Fedora for end-user people as simple as possible for this
function.
Leslie Satenstein
On Thursday, May 2, 2024 at 04:28:44 p.m. EDT, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote:
On 5/2/24 14:34, Gary Buhrmaster wrote:
> While I follow the philosophy of updating
> regularly, there are likely some who install Fnn, and
> never update, and then would expect an update to
> Fnn+2 to work without issue(s).
> --
The CLI update strongly suggests doing 'dnf update --refresh' before
system-upgrade. It doesn't require it though.
I always thought it's an odd workflow; why doesn't it just force it?
While it might take a long while to complete on a stale system, it's
recommended anyway, isn't it?
I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
11:20 a.m.
On Thu, May 02, 2024 at 01:28:19PM GMT, Adam Williamson wrote:
On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel
wrote:
> On 5/2/24 14:34, Gary Buhrmaster wrote:
> > While I follow the philosophy of updating
> > regularly, there are likely some who install Fnn, and
> > never update, and then would expect an update to
> > Fnn+2 to work without issue(s).
> > --
>
> The CLI update strongly suggests doing 'dnf update --refresh' before
> system-upgrade. It doesn't require it though.
>
> I always thought it's an odd workflow; why doesn't it just force it?
> While it might take a long while to complete on a stale system, it's
> recommended anyway, isn't it?
I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.
Perhaps the dnf5 version could be just:
dnf offline-upgrade
(and it automatically does --refresh and it downloads and then says "packages
downloaded, ok to reboot into the upgrade now? y/n)" ?
And if you pass it 'download' or 'reboot' it only does those steps?
kevin
10:28 a.m.
Hi Jan,
On Thu Apr 25, 2024 at 07:42 +0200, Jan Kolarik wrote:
We've prepared a side-tag for testing Rawhide with dnf5 as the
default
package manager. Instructions for installing the packages from the side-tag
can be found at the following link [1].
Thank you for the announcement. I appreciate the oppurtunity to test the
update before it's pushed to rawhide.
This contains an update to dnf 5.2.0 which has breaking API changes. I did not
see these communicated anywhere and the Change Proposal did not mention that
the update would include a major version bump at the same time as the switch to
dnf5 as default. This update completely breaks fedrq due to the removed
methods. ansible, lorax, and osbuild also depend on libdnf5. Have these
applications had a chance to port to the new API? Would it be possible to
provide a testing Copr and a porting guide so API users can fix their software
before this is pushed to rawhide?
Best,
Maxwell
1:46 a.m.
Hi Maxwell,
This contains an update to dnf 5.2.0 which has breaking API changes. I did
Sure, as mentioned earlier, there's a dnf5-testing COPR specifically for
these purposes:
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing.
... and a porting guide so API users can fix their software
> before this is pushed to rawhide?
We'll add a section about the API changes between dnf5 versions 5.1 and
5.2, and we'll reach out to the several teams affected by this. We'll also
ensure that the builds for our reverse dependencies are passing with this
update. We definitely don't want to push this before these projects are
fixed.
Still, I hope no harm has been done yet. That's actually the purpose of
this side-tag, to identify any gaps we may have missed while working on the
switch. The 5.2.0.0 API changes aren't significant, there are though many
ABI-breaking changes.
Thanks,
Jan
On Thu, Apr 25, 2024 at 5:29 PM Maxwell G <maxwell(a)gtmx.me> wrote:
> Hi Jan,
> On Thu Apr 25, 2024 at 07:42 +0200, Jan Kolarik wrote:
> > We've prepared a side-tag for testing Rawhide with dnf5 as the default
> > package manager. Instructions for installing the packages from the
> side-tag
> > can be found at the following link [1].
> > [1]
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
> Thank you for the announcement. I appreciate the
oppurtunity to test the
> update before it's pushed to rawhide.
> This contains an update to dnf 5.2.0 which has breaking
API changes. I did
> not
> see these communicated anywhere and the Change Proposal did not mention
> that
> the update would include a major version bump at the same time as the
> switch to
> dnf5 as default. This update completely breaks fedrq due to the removed
> methods. ansible, lorax, and osbuild also depend on libdnf5. Have these
> applications had a chance to port to the new API? Would it be possible to
> provide a testing Copr and a porting guide so API users can fix their
> software
> before this is pushed to rawhide?
> Best,
> Maxwell
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
not
see these communicated anywhere and the Change Proposal did not mention
that
the update would include a major version bump at the same time as the
switch to
dnf5 as default.
You're right; we missed this. I'm sorry about that. Our initial intention
wasn't to do a major version bump, but implementing the new functionality
without breaking ABI and API would have required a lot of extra work.
Would it be possible to provide a testing Copr ...
12:31 p.m.
Hi Jan,
On Fri Apr 26, 2024 at 08:46 +0200, Jan Kolarik wrote:
Hi Maxwell,
This contains an update to dnf 5.2.0 which has breaking API changes. I did
> not
> see these communicated anywhere and the Change Proposal did not mention
> that
> the update would include a major version bump at the same time as the
> switch to
> dnf5 as default.
>
You're right; we missed this. I'm sorry about that. Our initial intention
wasn't to do a major version bump, but implementing the new functionality
without breaking ABI and API would have required a lot of extra work.
That makes sense. I'm sorry if I was a bit harsh here.
Would it be possible to provide a testing Copr ...
>
Sure, as mentioned earlier, there's a dnf5-testing COPR specifically for
these purposes:
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing.
It looks like the packages in that Copr Obsolete dnf4, while I want to
keep using dnf4 on my f39 machine. I built my own dnf5 package without
the dnf5_obsoletes_dnf bcond locally, but it'd be nice to have pre-built
RPMs for that.
... and a porting guide so API users can fix their software
> before this is pushed to rawhide?
>
We'll add a section about the API changes between dnf5 versions 5.1 and
5.2, and we'll reach out to the several teams affected by this.
That would be great! It looks like work on this has started in
https://github.com/rpm-software-management/dnf5/pull/1456. Thank you.
We'll also ensure that the builds for our reverse dependencies
are
passing with this update. We definitely don't want to push this before
these projects are fixed.
Still, I hope no harm has been done yet. That's actually the
purpose of
this side-tag, to identify any gaps we may have missed while working on the
switch. The 5.2.0.0 API changes aren't significant, there are though many
ABI-breaking changes.
Yeah, as long as we make sure everything is ported before the side tag
is merged, we should be good to go.
I saw some patches for dnf 5.2.0 compatibility in ansible upstream, so
we may just need to backport those. As for fedrq, I have a WIP patch to
add compatibility for dnf 5.2.0. The only thing I have not been able to
figure out is [1]. I assume stable Fedoras will keep dnf 5.1.0, so the
plan is to maintain compatibility with those for now so users can still
opt in to the libdnf5 backend.
[1] https://github.com/rpm-software-management/dnf5/issues/1450.
Thanks,
Maxwell
12
days inactive
23
days old
22 comments
10 participants
participants (10)
-
Adam Williamson -
Gary Buhrmaster -
Jan Kolarik -
Kevin Fenzi -
Leslie Satenstein -
Matthew Miller -
Mattia Verga -
Maxwell G -
Michael J Gruber -
Przemek Klosowski