Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rpm build script #437

Merged
merged 3 commits into from
Nov 12, 2024
Merged

Fix rpm build script #437

merged 3 commits into from
Nov 12, 2024

Conversation

InHavk
Copy link
Contributor

@InHavk InHavk commented Sep 23, 2024

Reported as #436

Some small fixes of generating rpm packages

Copy link
Contributor

@kontura kontura left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you drop the spec file changes?
We keep this spec in sync with fedora downstream createrepo_c spec files and this would break our workflow. We are using the Github releases and those are tar.gz.

I would rather you update to make_tarball.sh.

@InHavk
Copy link
Contributor Author

InHavk commented Oct 27, 2024

Sorry for long waiting, I've lost notification.

Problem there not only with format of archive. That part is easy to fix without touching spec.

Source tar named as a %{name}-%{version}.tar.gz in spec and version is hardcoded also there. It means, that spec always will wait createrepo_c-1.1.4.tar.gz with createrepo_c-1.1.4 directory inside.

So, there is two ways:
1 - We can ignore refs as a version and make_tarball.sh always will make tar only with version that exact same as in spec. For instance, make_tarball.sh branchname will use branchname as source of code, but have createrepo_c-1.1.4.tar.gz in result.
2 - Add in spec some variable like GITREV with condition like if GITREV exist - use it as version, instead use hardcoded version. It shouldn't break building rpm in any other situation, if that variable hasn't used.

@InHavk
Copy link
Contributor Author

InHavk commented Oct 27, 2024

I've pushed fix of first part now (xz -> gz). But about second part (version) I need a decision. Because both of ways looks like "definitely not ideal".

@kontura
Copy link
Contributor

kontura commented Nov 7, 2024

I would find the condition is spec file less confusing so I prefer the second approach.

@InHavk
Copy link
Contributor Author

InHavk commented Nov 11, 2024

Someone had tried something like that before, because variable gitrev tried to insert in spec by sed. But nothing used it.

Also, I have found second problem that actually version is defined in two places for different purposes (spec + VERSION.cmake). It makes build a little bit more complicated, but solution was founded by using non-version-specific path for eggs in %file section of spec. It's again non ideal, but will work in every case.

@InHavk InHavk requested a review from kontura November 11, 2024 16:57
Copy link
Contributor

@kontura kontura left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sorry I didn't realize there will be a conflict and I bumped the version.
Can you please rebase?

Otherwise it looks good.

@InHavk
Copy link
Contributor Author

InHavk commented Nov 12, 2024

Yeah, no problem. Rebased

@kontura
Copy link
Contributor

kontura commented Nov 12, 2024

Thank you

@kontura kontura merged commit c571445 into rpm-software-management:master Nov 12, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants