Sorry but this feature will be removed in a future copr-cli release. The plan is provide the functionality in copr-rpmbuild. We are sorry for any inconvenience this might cause for you but we will do our best to provide the needed functionality in copr-rpmbuild. Let's work together on it. Please, give use feedback what we can do to improve the state of copr-rpmbuild. Thank you for your understanding.

I claimed many times that @clime blocks me on this issue, and here we are again
(closed issue before anyone had a chance to speak up).

So, here I asked everyone, not only @clime for concrete question. Can I,
please, take care of this functionality - at least till we have a 100% 1:1
replacement (working el6+, without additional deps, having the same mock config
content)?

If not, please clearly tell me why you don't want me to take care of it,
what problems it causes.

We are sorry for any inconvenience

You, actually don't care (don't speak for others, please) and that's why I
raise this again.

Let's work together on it.

I'll do, let me know what I can do about it. Once we are done with el6+, we can
drop 'copr mock-config'.

We are sorry if this upset you but the solution is not to reopen closed issues.

If you want to help, what you can do is to check the current state of copr-rpmbuild and file issues on aspects that don't suit you.

Kindly, thank you for your cooperation.

So, here I asked everyone, not only @clime for concrete question. Can I,
please, take care of this functionality - at least till we have a 100% 1:1
replacement (working el6+, without additional deps, having the same mock config
content)?

If you feel that it is worth your time, then how can I say "don't do it". As we discussed, our focus should be creating a copr-rpmbuild alternative (some plan should be established and smaller tasks created, so we can participate in it) but in parallel, if you want to fix bugs in the mock-config, then do it. But please know, that the ultimate agreed goal is to deprecate it, so don't be hurt when it happens.

You can ping me to review mock-config PRs, I am willing to +1 them. But someone else also needs to +1 it ...
However, the current state of the mock-config feature should be not-deprecated (PR#395 is not merged yet, but I am sure @msuchy will do it). Once it gets deprecated again, I see no point in spending another time on it. Personally, I just don't know when it will happen because there seem to be many opinions on it and I am afraid that additional discussion will have to happen. Not here though.

I didn't want to edit the issue metadata and Re-open it after @clime's last close. It was a pagure bug.

I didn't want to edit the issue metadata and Re-open it after @clime's last close. It was a pagure bug.

I am closing again and then to avoid any confusion about this then. I am sorry about this situation but there is a clear constructive way from here. It would be good to just do the work.

If you feel that it is worth your time, then how can I say "don't do it".

Absolutely, it so important (there's some vision behind it I try to explain you for some time) so I'm really motivated. Motivated enough to keep that code alive even if @clime forced me to fork the code into separated copr-mock-config project, which is ultimately bad idea.

But please know, that the ultimate agreed goal is to deprecate it,

I don't agree with that, since the current code costs nothing. Note that I haven't designed copr-rpmbuild as a client tool (that day it was called copr-bulider). I had some vision that:
1. we need to have a package which - when installed - completely prepares builder
2. and can be used trivially to debug build failures

Instead, the first purpose is getting overlooked and we plan to claim that good place for copr mock-config is copr-rpmbuild, which:
- won't ever work on el6
- won't work on el7 most probably (RHEL 7.7 is mostly unrealistic timing for new features)
- has a serious dependency bloat, because it should serve point 1.

Do you see how that is a bad idea? I can elaborate more, please ask.

More, I know that @clime claims that koji mock-config was a mistake (and copr shouldn't repeat the same mistakes, huh?), but I disagree with him. It's IMO 100% OK to have this functionality in /bin/copr.

So, while 100% agree that copr-rpmbuild should be developed -- I don't want to break it's original purpose (or we should start thinking about yet another package, maybe reuse copr-builder for that).

so don't be hurt when it happens.

I won't, once that happens I'll have to migrate those few lines into different upstream. But I'm desperate, can we please evaluate the cost of keeping the code? And sumup the motivation? Is it worth the money?

What I keep hearing -- "it will go away" with no real reasons. I agree that "hypothetically" we could have 1:1 replacement one day (and it's not today, nor tomorrow), but it's not good for the project and it's neither realistic.