fedora-docs / package-maintainer-docs

#52 New_Package_Process_for_Existing_Contributors needs to be updated to include non `fedpkg import` method
Opened by ankursinha. Modified

Open
Close Issue

when folks use rpmautospec, they can no longer use fedpkg import because the SRPM has the expanded form of the rpmautospec macros. Using fedpkg import also throws away the git history. So, we need to document how to import a package without using fedpkg import.

See this thread for more info:

https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/YEU4U72X6PWZWWNTPF755W5JIQ3IVHXH/

Steps (need to be verified):

  • add the SCM as new remote: git remote add origin ...
  • fetch it: git fetch origin
  • set it as the remote: git branch main -t origin/main
  • rebase the branch on top of the SCM's branch: git rebase origin/main

I think this has other caveats though:

  • one has to run fedpkg new-sources manually to upload the sources to the lookaside cache
  • one has to make sure no other files are in the repo now (sometimes folks include the srpm there during review etc.)

CC: @vondruch @churchyard

This would probably deserve its own page, because:

  1. This is common issue for New_Package_Process_for_New_Contributors.adoc as well as for New_Package_Process_for_Existing_Contributors.adoc, so both could refer to this workflow.
  2. This is IMO very similar situation to git init local repository you'd like to push later into GH created repo.
  3. The New_Package_Process_for_Existing_Contributors.adoc would deserve overhaul on its own. It is interesting that this page contains paragraphs such as "** If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this." while this would probably belong to the New_Package_Process_for_New_Contributors.adoc.

However, part of this are pure git tricks, while the others are fedora specific tricks, not sure how combine these ...

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

And BTW, part of the issue might be already resolved actually:

https://pagure.io/rpkg/pull-request/560

I have just never found the cycles to try the final implementation :see_no_evil:

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

And BTW, part of the issue might be already resolved actually:

https://pagure.io/rpkg/pull-request/560

I have just never found the cycles to try the final implementation :see_no_evil:

So this works:

$ fedpkg remote add --remote-name origin --repo-name my-new-package

However, it adds just anonymous URL :/

However, it adds just anonymous URL :/

Request of non-anonymous URL is here:

https://pagure.io/rpkg/issue/599

Yeh, it'll be good if we can teach fedpkg all of this, otherwise it can be quite a complex process, especially for newcomers who are meant to benefit from fedpkg usage. I had to write this all up for our Outreachy intern:

https://pagure.io/neuro-sig/NeuroFedora/issue/496#comment-773460

Now, they had committed other files to the SCM etc, so there were extra steps to get things done. It's really not a simple process at all. I'm now wondering if I should've asked them to use fedpkg import and then correct the spec instead---we'd lose git history, but it'd be wayy easier!

However, it adds just anonymous URL :/

Request of non-anonymous URL is here:

https://pagure.io/rpkg/issue/599

This has been resolved upstream. Not sure when it lands in Fedora though.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.