F22 System Wide Change: Replace Yum With DNF

Reindl Harald h.reindl at thelounge.net
Wed Jun 11 14:30:03 UTC 2014

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140611/996ffb63/attachment-0001.sig>

More information about the devel mailing list