To distro-sync or not distro-sync?

Reindl Harald h.reindl at thelounge.net
Thu Oct 29 13:20:50 UTC 2015



Am 29.10.2015 um 14:18 schrieb Zbigniew Jędrzejewski-Szmek:
> On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
>>
>>
>> Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
>>> On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
>>>> You have a chance to get your rpmfusion softwares wiped after the sync.
>>>>
>>>> [1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
>>>
>>> yep, so not distro-sync
>>
>> nonsense when i read the bugreport
>>
>> * system-upgrade now uses dnf (standard "dnf update" approach)
>>
>> THAT is the problem and i really wonder what somebody thinks by
>> implement it that way after *many years* of "yum --releasever=XX
>> distro-sync" works absolutely relieable
>>
>> * change "dnf update" mode during system upgrade to
>>    "dnf distro-sync --allowerasing"
>>
>> THAT is the right direction but nonsense because --allowerasing is a
>> terrible idea, anyways "dnf --releasever=XX distro-sync" is not
>> affected by both wrong solutions as far as i see (expect DNF is
>> intentionally or unintenioally broken elsewhere there)
>
> There are three options:
> (1, no distro-sync) — upgrade only packages which can be upgraded
>    without conflicts. Leaves a partially upgraded system in some cases.
> (2, distro-sync) — upgrade packages which can be upgraded, remove
>    conflicting ones. Lose some packages during upgrade.
> (3, force) — upgrade all packages ignoring conflicts. Leaves the
>    system with some programs broken.
>
> You seem to dislike all the options, but I don't see anything else
> possible. Do you have some better proposal?

just behave like "yum --releasever=XX distro-sync" all the years before 
and just REFUSE to upgrade if there are conflicts because anything else 
is undefined behavior

DNF just needs to give enough information how to solve the dependency 
problems

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151029/5f09edb2/attachment.sig>


More information about the devel mailing list