Here are the el7 friendly rpkg and copr-rpmbuild packages https://copr.fedorainfracloud.org/coprs/praiskup/copr-rpmbuild/monitor/

Thank you but I decided not to include rpkg in el7 especially for the lack of --merged option. Can you give some motivation for this PR? Quickly looking at the code, the --merged is handled in a very hacky manner that would be horrible to maintain. Also the macro part should be independent of python. --exclude-vcs-ignores for git_pack is not implemented correctly. The changes are very extensive and currently we don't have overall regression tests to make this works for all the cases. Anyway, the main problem is lack of --merged for the old Git in EPEL7. That's why decision was made not to include rpkg there. Unless, there is a good motivation and good way to fix the implementation, I think the decision should be kept.

Can you give some motivation for this PR?

Some Copr builders in Internal Copr are long-term running boxes in not really stable cloud -- so I need them to run on EL7, otherwise I'd have to upgrade fedora all the time. Upgrading fedora has huge risk that something get's broken, and I won't be able to fix that without support...

Quickly looking at the code, the --merged is handled in a very hacky manner

Uh uh, even though it's not exceptionally hacky compared to all the other code (I've spent many hours getting it working, because I was convinced that you'd refuse to do it..), so please suggest better style :-)

--exclude-vcs-ignores for git_pack is not implemented correctly.

Good catch ;) there's TODO for it; nor in GNU tar (pretty new stuff); I'd vote to not use that at all and only implement it in rpkg-util; otherwise you won't ever know when that functionality changes.

I have expected your reaction (I won't merge, while you don't say what/how to fix); so I have other proposal, what about to not depend in copr-rpmbuild on rpkg-util at all?

Some Copr builders in Internal Copr are long-term running boxes in not really stable cloud -- so > I need them to run on EL7, otherwise I'd have to upgrade fedora all the time. Upgrading fedora > has huge risk that something get's broken, and I won't be able to fix that without support...

I understand the limitation...I would suggest to wait it out for a next EPEL release, however, instead of bending the existing tooling now. Alternatively, you could try upgrading Git and tar on the builders if you don't mind being dependent on copr package. I was actually able to install and "use" Git (I just tried git --version actually) from https://copr.fedorainfracloud.org/coprs/g/git-maint/git/ on CentOS7 so I recommend taking look at it. That could be a very nice solution. I haven't look for a newer tar though.

Ok, forget about that. I'll fork this "tool" which you refuse to accept patches for.

Please document why you refuse to porting this tool against the EPEL 7, thanks, #12.

Thanks for the discussion and the constructive approach.

Added pull request summary:

Making a dedicated copr with required version of tar and git is a better approach to get rpkg-util working on EPEL7 because it doesn't require very significant changes in the current code-base that can't even be properly tested at the moment. Also the proposed implementation is incomplete with respect to git_pack macro with very difficult implementation bits left and the implementation of --merged switch for Git is very hacky and can't really be accepted as a proper solution.

Making a dedicated copr with required version of tar and git is a better approach to get rpkg-util working on EPEL7 because it doesn't require very significant changes

Huh?

in the current code-base that can't even be properly tested at the moment.

This is nonsense. Please provide el7 version, and let people report the bugs.

Also the proposed implementation is incomplete with respect to git_pack macro with very difficult implementation bits left

Be concrete and constructive, before you close pull requests. Thanks!

and the implementation of --merged switch for Git is very hacky and can't really be accepted as a proper solution.

Please define how that is hacky, and how that should be implemented.

This PR has been migrated to GitHub as a placeholder issue:
https://github.com/fedora-copr/rpkg-util/issues/11