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

macros: Add %version_notilde #722

Conversation

ignatenkobrain
Copy link
Contributor

This has been originally part of rust-srpm-macros under
%version_no_tilde, but people asked to move to RPM because more and more
packagers started to use tilde version.

Signed-off-by: Igor Gnatenko i.gnatenko.brain@gmail.com

This has been originally part of rust-srpm-macros under
%version_no_tilde, but people asked to move to RPM because more and more
packagers started to use tilde version.

Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
@@ -335,16 +335,16 @@ package or when debugging this package.\

# A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
#

Choose a reason for hiding this comment

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

Why give someone a reason to reject this just because it includes unrelated whitespace changes?

Copy link
Member

Choose a reason for hiding this comment

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

Indeed...

@jasontibbitts
Copy link

This sort of seems the kind of thing that would go in to redhat-rpm-config (or another distro-specific package) first instead of straight upstream to RPM. But I guess I don't fully understand how new macros are expected to flow into RPM these days.

@ignatenkobrain
Copy link
Contributor Author

@jasontibbitts well, nowadays we try to avoid pushing anything to redhat-rpm-config if it would be useful for others. For some things which need more testing or thinking, redhat-rpm-config should be the first place... But for things like this I don't see any reason to not get it straight in RPM.

macros.in Show resolved Hide resolved
@pmatilai
Copy link
Member

pmatilai commented Jun 3, 2019

Macro expansion internals aside, I do wonder. Where's %version_nocaret? (no, I dont want to see that either, but I sense there may well be something here)

What's the actual use-case?

@ignatenkobrain
Copy link
Contributor Author

So the upstream tarballs are never using tilde in their version, they are more like 3.8.0a1, 2.0.0-alpha.8 and so. We have to use our own versions with tilde in spec files. So use-case is easily get from tilde-version back to the upstream tarball (directory) names.

@pmatilai
Copy link
Member

pmatilai commented Jun 3, 2019

Right. And caret presents a similar case. /me mumbles something about "upstream version" sounding closer to the mark.

@ignatenkobrain
Copy link
Contributor Author

Yeah, actually caret usually is used for parts which are not part of upstream version. like 1.0^2019git.deadbeef. So what about %upstream_version which will replace/remove tilde and remove entirely part after caret?

@pmatilai
Copy link
Member

pmatilai commented Jun 3, 2019

Something to that direction maybe.

This also makes me think about the case in #715...

# -v<version> Sets the version to be used for replacement. Default is %version.
%version_notilde(v:) %{lua:
local sep = rpm.expand('%1')
local ver = rpm.expand('%{!-v:%{version}}%{-v:%{-v*}}')
Copy link
Member

Choose a reason for hiding this comment

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

Another remark here is that you might want to use %{VERSION} as the default instead - that will always refer to the main package version, whereas %{version} will point to whatever the last Version: tag in the spec was (it's rare but sometimes sub-packages have their own versions).

@pmatilai
Copy link
Member

There might well be a case behind this, but not in this form. Lets close this and continue elsewhere.

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.

3 participants