I think it's entirely up to you.
The source tree in Fedora uses "main" for the Rawhide version of the package and f32, f33, etc. for releases. Also, the %changelog in the SPEC file is in a way an immediate history of the SPEC file, including versioning and revisions.
I usually keep external SPEC files on GitHub and use a linear history with a single "master/main" branch, but it does make sense to leverage git tags or versioned branches if you intend to keep multiple versions worth of the SPEC file.
~Andy
On Tue, 29 Dec 2020 at 22:19, FreedomBen <freedomben@xxxxxxxxxxxxxx> wrote:
rpmlint complains (which I fully expected from reading the packaging guidelines) about my spec file being named "pick-v4.0.0.spec" instead of "pick.spec".What's the best way to manage spec files for different versions? git tags in the repo? directories with version info? something else?BenSent with ProtonMail Secure Email.‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Monday, December 28, 2020 1:53 PM, Andy Mender <andymenderunix@xxxxxxxxx> wrote:On Mon, 28 Dec 2020 at 21:12, FreedomBen via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:Hi all,I've read a crap ton of pages now about package creation/maintenance but feel like I'm missing stuff and spinning wheels so I wanted to ask. The process seems pretty muddled :-DI've got an RPM package I maintain called "pick" (I'm already working with the upstream project and have their blessing/encouragement to do this). It's a reasonably successful project that really should be in the official repos. Here's the upstream: https://github.com/mptre/pickHere's an example spec file I use. I have a scrip that generates these automa6tically based on the version available upstream: example spec file: https://github.com/FreedomBen/pick-rpm/blob/master/spec-files/pick-v4.0.0.specThe build of my build is this script (https://github.com/FreedomBen/pick-rpm/blob/master/build.sh) plus the Dockerfile (https://github.com/FreedomBen/pick-rpm/blob/master/Dockerfile). That's probably not relevant for what we're doing here, just wanted to share in case it's useful for somebody evaluating me ;-)I have a COPR repo now for "pick" here: https://copr.fedorainfracloud.org/coprs/freedomben/pick/:All my scripts I use to build RPMs are here. Basically I just use podman to crank out all versions. There's a script to generate a stand alone spec file as well (which is where the one above came from): https://github.com/freedomben/pick-rpmI want to get this package included in Fedora proper. I've never been a Fedora maintainer before but I'm a long time Fedora user and programmer and generally pretty good at stuff kind of guy. I'm mostly familiar with packaging guidelines, though I'm not an expert on the various macros (yet).Is there someone who can guide me on what to do next? Or who will sponsor me?Thanks in advance,BenHello Ben!I see "pick" is available on quite some platforms! :)The simplest approach would be to submit a request to add your package to Fedora at: https://bugzilla.redhat.com/Here are the links I usually use for reference:- On becoming a packager: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join- Packaging Guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/- An in-depth guide to RPM packaging (slightly outdated, but still useful): http://ftp.rpm.org/max-rpm/- On getting sponsored: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_groupYou're already on the right track with your SPEC file from what I saw. What I'd recommend is the following:1. Read through the above docs to make sure you have all the necessary tools like "fedora-review", "rpmlint", "mock" and "rpmbuild".2. Generate a RPM and SRPM of your package and check it with the above tools to make sure it's clean.3. Submit a review request to https://bugzilla.redhat.com/ and mark your request as blockingthe FE-NEEDSPONSOR tracker so that people are aware that sponsorship is required. Be sure to link the SPEC file, a SRPM generated via "rpmbuild" and a successful Koji scratch build (not mandatory, but it helps).
4. Wait for someone to pick up your request and join us ;).
Cheers,
Andy
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx