<p dir="ltr"><br>
On Apr 13, 2015 5:07 AM, "Radek Holy" <<a href="mailto:rholy@redhat.com">rholy@redhat.com</a>> wrote:<br>
><br>
><br>
> ________________________________<br>
>><br>
>> From: "Pete Travis" <<a href="mailto:lists@petetravis.com">lists@petetravis.com</a>><br>
>> To: "Development discussions related to Fedora" <<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a>><br>
>> Sent: Friday, April 10, 2015 5:31:08 PM<br>
>> Subject: Re: dnf replacing yum and dnf-yum<br>
>><br>
>><br>
>><br>
>> On Apr 10, 2015 4:39 AM, "Radek Holy" <<a href="mailto:rholy@redhat.com">rholy@redhat.com</a>> wrote:<br>
>> ><br>
>><br>
>> ><br>
>> > 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 :( )<br>
>> ><br>
>> > Anyway, file an RFE (if it isn't filed already) please. We can track/discuss it there.<br>
>> ><br>
>> > Thank you in advance<br>
>> > --<br>
>> > Radek Holý<br>
>> ><br>
>><br>
>> (lots of trimming, and skipping an RFE, as this just pertains to the distro-sync use case question)<br>
>><br>
>> 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:<br>
>><br>
>> 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.<br>
>><br>
>> 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. <br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> And yeah, it is very useful for upgrades. Even when ran after a proper fedup upgrade. <br>
>><br>
>> --Pete<br>
>><br>
>><br>
> 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.<br>
><br>
> 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<br>
> -- <br>
> Radek Holý<br>
> Associate Software Engineer<br>
> Software Management Team<br>
> Red Hat Czech<br>
><br>
> --<br></p>
<p dir="ltr">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.</p>
<p dir="ltr">--Pete</p>