I'm +1 to killing off YUM 3. I'm ambivalent about renaming DNF to YUM 4.

@kevin in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4ANJI5BPX2RYPNXNGJKGHQCXIYRUKIKS/ raises some important points. Looking at the list of things which would interfere with releng and infra work, removal of yum would be very disruptive at this point. It is possible to work around this by doing various tasks on RHEL instead of on Fedora, but imho this is the wrong direction. We should be able to dogfood everything, which means that the important tools which still use yum need to be ported or replaced first, and only then should yum be removed from the distribution. Doing it now would just make things significantly harder for releng and infra, and people who do anything related, and this outweighs any benefit of removing those packages.

pungi, koji, libtaskotron, retrace-server, sigul, dnf-plugins-core seem to be the minimum that needs to not depend on yum before this happens. I think this change can be realistically targeted at F30 at best, and should only happen after tools in this list are ported or replaced.

According to https://bugzilla.redhat.com/show_bug.cgi?id=1156501, "Current Fedora composes all use DNF backend for depsolving.". Does this mean that the deps onyum and yum-utils can be removed?

pungi, koji, libtaskotron, retrace-server, sigul, dnf-plugins-core seem to be the minimum that needs to not depend on yum before this happens. I think this change can be realistically targeted at F30 at best, and should only happen after tools in this list are ported or replaced.

I tend to agree with @zbyszek here -- consider me -1 to this change unless RelEng is completely comfortable with the change, at which point I'll gladly change my vote to a +1.

I'd also consider moving this to a system-wide change, as it obviously isn't really "self-contained".

+1

-1 for now

+1 to the change and renaming when rel-eng is ready for it. Not sure what we are voting on, here, actually. As far as I understand we vote on the plan to do the change, not that the change is now ready to be executed.

My understanding (and please correct me if I'm wrong) is that we've voting that this change be approved for the F29 release cycle. Hence my concern about whether RelEng is actually ready for it to happen so soon.

@dmach can you answer my questions on the list? I think your list has false positives and/or could be clarified. Or I guess I can just use this ticket to ask people...

dnf-plugins-core - I don't see any dep here?
koji - not sure what part of koji this is also. Fedora infra runs koji (currently) on rhel7, so we would likely be ok here for now.
koji-containerbuild - there is a python2 dep here, but I don't see yum?
libtaskotron - @kparal can you address this? what impact will it have to drop yum for libtaskotron?
mirrormanager - again we run this today on rhel7, so fedora-infra has time for python3/dnf porting.
retrace-server - runs on rhel7 today
rpm-ostree-toolbox - @walters / @dustymabe can you address this? what impact will dropping yum have here?
sigul - @puiterwijk can you address this? what impact will dropping yum have on sigul?

And then we come to mock. :(

Fedora infrastructure is using a old mock version ( mock-1.3.4-2.infra.fc28 / fc27) because the ones right after it had some bugs we hit. We can of course try upgrading to the newest versions, but it will take time. Also, we will need to default to old-chroot (because new-chroot doesn't work with runroot jobs or kernel builds), but thats a side detail. Also, after this change epel builds will have to start using dnf instead of yum to build. This will mean that a local build on a real rhel box with yum could be different from a dnf populated build in koji. I suppose we have to just bite the bullet someday.

So, in short I think we can possibly do this, but it depends on the answers above from libtaskotron, sigul and rpm-ostree-toolbox and if I missed anything in the above deps.

We can retire rpm-ostree-toolbox; I just orphaned it. FWIW our future CoreOS build efforts will focus on being delivered as containers inside Kubernetes/OpenShift.

libtaskotron - @kparal can you address this? what impact will it have to drop yum for libtaskotron?

We seem to be in the list because of requiring createrepo. I'll switch to using createrepo_c asap, should be trivial.

I just checked, and sigul shouldn't have (and doesn't seem to have) a dep on yum at all.
It uses rpm-utils, but not yum.

So, with all that I guess I can be +1. I'd really wish mock bootstrap support was working and support for it was in koji, but I suppose we can scramble to add that before we need to update builders to f29.

After 1 week, I count the vote as +4/-1. I will mark this change approved.

Hmm, I don't think the process is working here. Discussion is clearly still going on (@puiterwijk's comment that clarifies technical issues is 5h old). It's not realistic for everyone to look and respond within a few hours.

Also, the count looks wrong. I voted -1, and so did @jsmith. His vote was conditional, but the condition seems to be still true, so the tally should be +3/-2. If he wants to change his vote, please wait for him to do this himself.

Also, this should not be approved. The rules are pretty clear: "Any "against" votes mean that it goes onto the next meeting agenda. ".

@zbyszek you're correct on the count. When evaluating ithe issue yesterday, I was referring to the email Stephen sent that said "So long as at least three members have voted, the majority of votes at the end of that week will be counted as the result." which conflicts with the policy on the wiki page. I'll follow the wiki policy going forward.

I'll move this change back into a waiting for approval status. I apologize for the mistake. Thanks for your patience as I get used to the role.

FWIW, I was confused about the rules. Initially, I wrote the comment above without the third paragraph, but then I looked at the rules on the wiki page and added it. I guess it came out more negative than I intended, sorry for that.

Regarding koji dependencies on yum (which is not listed explicitly in the SPEC): https://bugzilla.redhat.com/show_bug.cgi?id=1591772#c1

Fedora/RISC-V lives on a separate koji instance that follows upstream koji (the official one). I would prefer to have koji-infra packages install and work in Fedora 29/Rawhide.

Also kojid (koji-builder) by default still uses createrepo instead of creatrepo_c, but you can flip that in kojid.conf.

This definitely needs some prep work to have a clean removal.

Ugh. I just saw in https://pagure.io/koji/issue/971 that kojid also uses yum currently.

If not too late I am going to change my vote to -1 here and ask that this be deferrend until mock and koji are ready for it. Or get some commitment someone will have those fixed as part of this change.

Pretty much that has been said already. I'm against this change until all of the infra/releng dependencies are resolved.

To me it would make sense to defer this to F30 and ensure all of that work is planned and tracked so that we're ready in time.

Yeah, I'm revising my vote to -1 as well. I'd like to see the Change owners talk with rel-eng and infra-tools about a timeline commitment first.

This was discussed in today's meeting:
AGREED: The change is rejected for F29, but FESCo would like to see this resubmitted for F30, with a list of dependencies (tickets), that need to be solved first (+7, 0, 0)

Can we actually deprecate yum (and friends) instead for now? I mean, mark it deprecated.

It's already called "yum-deprecated". I don't think playing witih metadata is going to give us much.

@jmracek approached me at devconf about the revival of this.

Can we get it done in Fedora 30?

My concern is that if we don't remove yum 3, nothing stops using it. We need to remove it and see what would break.

My proposal is to get this approved for 30 and if infra or releng or epel is not ready, let them maintain yum in copr or anywhere they want. Sorry if that sounds evil, but unless we do this radically, it won't ever happen.

The deadline for Self-contained changes is Tuesday. If @dmach wants to resubmit or if someone else wants to submit it, there's still time. I agree that the only way to do this is to rip the bandage off. My question would be do we get any benefit from doing it at the beginning of a release cycle instead? I'm guessing "no" because uses of yum are going to mostly be in user scripts and the like.

I suppose @jmracek would take over and resubmit by Tuesday. I've reopened this to revive the discussion.

I don't think delaying this any further would help. At worst we make this a Fedora 30 change, we realize it breaks the world, we bring it back and postpone to 31.

I suppose @jmracek would take over and resubmit by Tuesday. I've reopened this to revive the discussion.

Resubmitted: https://pagure.io/koji/issue/1214

See https://fedoraproject.org/wiki/Changes/Retire_YUM_3