F22 System Wide Change: Replace Yum With DNF

[drago01]

On Wed, Jun 11, 2014 at 4:30 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
> Am 11.06.2014 16:20, schrieb drago01:
>> On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>>
>>> Am 11.06.2014 16:08, schrieb drago01:
>>>> We should really just do the right think and properly obsolete yum
>>>> without a compact package ... keeping yum serves no purpose. As for
>>>> Matthew's mail ... I don't think people will forgot about Seth because
>>>> yum is gone if that's the case it would be really sad.... also why
>>>> maybe his biggest yum was not his only contribution
>>>
>>> if it obsoletes and replaces yum it has to provide /usr/bin/yum
>>
>> That's what I have said (just with the "if").
>>
>>> [...]
>>> and yes i think it would be a great idea install DNF only on
>>> new F22 setups while obsolete and replace yum finally one
>>> release later to get more widely testing and at the same
>>> time avopid to break 5 and more years old server setups
>>> with scripting around yum because some of the early bugs
>>> maybe be reported by the users of new install and fixed
>>> until F23
>>
>> No I disagree here. We already have (and are still in) a "optional to
>> test for user" and it gets active testing. Its time to flip the switch
>
> well, that's something different than have on a new setup DNF instead
> YUM and if things are working properly you don't notice, make a reality
> check: the way a optin-user tests and classifies things are completly
> different as a random user not knowing about the replacement
>
> if sensible core components are replaced there should be a way back
> in case of troubles and not a dry "there where testers live with it"
>
> those testers until now maybe not represent the relevant usecases
>
> if i replace software i do it always in steps and that is why
> i did not breaks cumstomers setups the last 11 years:
>
> * internal tests
> * asking some representative users for testing
> * update a picked set of users without saying anything
> * if they report troubles try to fix them within 2 up to 5 hours
> * if that's not possible revert the change for them
> * try to fix the problem without angry users
> * roll it out again for the picked set
> * and then roll it out for everybody
> * and even in that last step there must exist a way back
>
> the golden rule for accepted big changes is *never* break users setup
> and never make a abusive change with no way back and leave only
> telling him he has to chew and adopt

Sure but that should also applies to upgrades (i.e do not just upgrade
on productive systems without prior testing on a replicated test
environment; which you probably do anyway).

I am not really opposed to having "a way back" if it is opt in and not
simply split the userbase based on how the system got installed (this
is a mess to support comparing to having a handful of users that opted
to "go back"). Support aside at least the workstation prd states that
upgrades should not have a worse expirence then new installs having a
slower depsolver / package installer would fall into that.