----- Original Message -----
From: "Pete Travis" <lists(a)petetravis.com>
To: "Development discussions related to Fedora"
<devel(a)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" < rholy(a)redhat.com
> wrote:
>
>
> ________________________________
>>
>> From: "Pete Travis" < lists(a)petetravis.com >
>> To: "Development discussions related to Fedora" <
>> devel(a)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" < rholy(a)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