----- Original Message ----- > From: "Pete Travis" <li...@petetravis.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Tuesday, April 14, 2015 5:18:15 PM > Subject: Re: dnf replacing yum and dnf-yum
> On Apr 13, 2015 5:07 AM, "Radek Holy" < rh...@redhat.com > wrote: > > > > > > ________________________________ > >> > >> From: "Pete Travis" < li...@petetravis.com > > >> To: "Development discussions related to Fedora" < > >> devel@lists.fedoraproject.org > > >> Sent: Friday, April 10, 2015 5:31:08 PM > >> Subject: Re: dnf replacing yum and dnf-yum > >> > >> > >> > >> On Apr 10, 2015 4:39 AM, "Radek Holy" < rh...@redhat.com > wrote: > >> > > >> > >> > > >> > Hm, I think that it depends on the use case. AFAIK, distro-sync is > >> > mostly used to upgrade Fedora (an unsupported approach AFAIK) and to > >> > replace some testing/3rd-party versions of package with the "official" > >> > ones. (BTW, I'd appreciate if anyone will share their use case) While > >> > in the first case, I think that the upgrade's behaviour is preferred, > >> > in the other case, the install's behaviour is better IMO. (Which > >> > dangerously indicates that the --skip-broken switch is a good solution > >> > :( ) > >> > > >> > Anyway, file an RFE (if it isn't filed already) please. We can > >> > track/discuss it there. > >> > > >> > Thank you in advance > >> > -- > >> > Radek Holý > >> > > >> > >> (lots of trimming, and skipping an RFE, as this just pertains to the > >> distro-sync use case question) > >> > >> distro-sync is useful for getting to a sane state after temporarily > >> enabling some repo that interacts with the primary ones. This can happen > >> with third party repos, but we can consider an entirely in-house > >> situation: > >> > >> The user finds a bug in widget-2.5.7 and reports it. A fix for widget is > >> shipped and the user is asked to test via `dnf update widget --enablerepo > >> updates-testing`. The transaction pulls in many requires from > >> updates-testing (although at this point, I realize dnf may not be > >> upgrading the requires in this transaction if they are not versioned). > >> The new widget is tested, life goes on. > >> > >> Later, the user wants to install or update some package whizbang that > >> shares requires with widget. That package has versioned requires on > >> packages from the updates repo, but some of the installed packages are > >> from updates-testing and don't provide what whizbang needs. > >> > >> Something like `dnf --allowerasing install whizbang` might be the > >> appropriate and precise tool to get through that transaction. `dnf > >> distro-sync` is the less precise, big-hammer tool for the user that > >> doesn't know or care to track down the intricacies of widget and whizbang > >> dependencies. They ran some command from a bug report a while ago and > >> moved on, and now they run distro-sync to return their system to a > >> known-good state and move on. > >> > >> This sort of thing is most common during the prerelease cycle, when users > >> will have updates-testing on then off, and there are freezes, and > >> branching, and lots of activity that might leave early adopters in an > >> unsane state. > >> > >> And yeah, it is very useful for upgrades. Even when ran after a proper > >> fedup upgrade. > >> > >> --Pete > >> > >> > > Yeah, that's basically what I meant by 'replace some testing versions of > > package with the "official" ones'. Anyway, thank you for elaborating on > > it. I'll definitely make a test case from it. > > > > I'd like to let those doing the actions described above know that there is > > also a not very well known command "dnf repository-packages <repoid> > > remove-or-distro-sync" which is specifically designed for switching from > > packages installed from testing/3rd-party repositories > > -- > > Radek Holý > > Associate Software Engineer > > Software Management Team > > Red Hat Czech > > > > -- > Nice! That's <repoid> as the stable/updates repo, not the > testing/3rd-party/problem repo, right? I'll add this to my dnf writeup. > --Pete No, <repoid> as the testing/3rd-party/problem repo. It selects the packages installed from <repoid> and runs distro-sync or remove on them while the upgrades/downgrades are taken from all the enabled repositories except <repoid>. So, in the end, it's very likely that you'll end up with an RPMDB that does not contain any package installed from <repoid>. This command was taken from YUM and although it is not sometimes clear what the command should do without looking into man pages, I think that it's good as it is. If you want to control from which repositories are the upgrades/downgrades taken, combine it with --disablerepo, --enablerepo. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
