Yup. This is certainly in the right direction, but what I meant is using the
same extension for both binary and source packages (the code seems to support
it here already), and for that the NVRS name seems strange.
--
You are receiving this because you are subscribed to this thread.
Reply to
The new tags need to be added in tests/rpmgeneral.at. The change trips up a few
more test cases:
https://semaphoreci.com/rpm-ecosystem/rpm/branches/pull-request-1116/builds/3 >
view more > open "Fedora Latest" at very bottom > open "docker run -t rpm" >
scroll to the very end - or run the test
@vathpela pushed 1 commit.
5fa11af61ae2545ad94f351379222829810bb020 Make "rpmspec -q --srpm foo.spec" say
.src, not .%{arch}
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Having rpmspec default query match with what rpmbuild produces seems like a
nice idea, the implementation is what I have some issues with, primarily that
the new default is a magic internal behavior that you can't use it in other
queries. I think this belongs to a tag extension, RPMTAG_PKGNEVRA
> What about nosrc packages?
It's a bit harder to do well, as "rpmspec -q" goes through rpmcliQuery(), which
doesn't parse the spec file, and rpmspec.c doesn't know about rpmSpec
internals, so can't access spec->noSource without including
rpmbuild_internals.h, but I've pushed an updated patch
What about nosrc packages?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1116#issuecomment-598149647___
Rpm-maint mailing list
I noticed that rpmspec -q --srpm foo.spec winds up getting evaluated
as the arch that youre running it on, which I expected, but also that
the arch winds up in the output, which I did not. I asked a pile of
other people and they were all surprised by this as well.
This patch changes rpmspec -q
