Learn more about these different git repos.
Other Git URLs
This is not a pure issue, but rather asking a question that may turn into issue. I could not find pointers to a mailing list of similar place for general discussion, so forgive me for (mis?)using the issue tracker for this purpose.
When packaging new software for Fedora, one possible workflow is to initialize a local Git repository, then build the initial specfile and other dist-git content there. The main advantage there is that rpmautospec can be taken into use from the outset.
Currently, using fedpkg with such local Git repository suffers from an annoying issue: For every fedpkg operation, --release argument needs to be specified, because automatic determination for its value is based on the remote branch name. This feels unnecessary, a reasonable fallback would be use the local branch name.
fedpkg
--release
It looks like such change would be very easy to do in function load_branch_merge of pyrpkg/__init__.py. just using (already resolved) local branch name instead for raising an exception should be enough.
load_branch_merge
pyrpkg/__init__.py
Is there some reason that local branch name is not suitable for such use? Can I just send a pull request for using the local branch name as default?
I think it would also make sense for fedpkg to fallback to --release rawhide if there is no git repository or if the branch name doesn't match up to any release.
--release rawhide
I like the idea of just defaulting to Rawhide if there is no Git repository. Of course that cannot be implemented in rpkg only, but rpkg could provide a hook where different x-pkgs can set their own defaults, with the "default default" being the current behavior of raising an exception.
rpkg
Just this change would significantly simplify using fedpkg for packages without dist-git remote. And as gotmax23 recently educated me, rpmautospec has working defaults even without any repository.
Pull requests: #645 and fedpkg#495
Both pull requests have been merged, so I close this issue now.
Commits fixing this issue:
Metadata Update from @oturpe: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @onosek: - Issue set to the milestone: 1.66
Login to comment on this ticket.