> It would be deeply flawed if rpmbuild(8) allowed an invalid spec file to be
> used for a package build.
Indeed, and that's really all there is to it. We cannot allow rpm to generate
source / binary packages with an unparseable/inconsistent spec. Find another
way to do whatever it is you're d
Closed #674.
--
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/issues/674#event-2293258491___
Rpm-maint mailing list
Rpm-maint@lists.rpm
@Conan-Kudo `BuildRequires` are not attached to the subpackage, they’re
attached to the srpm, they are not part of “subpackage evaluation”. What trips
eclipseo is not srpm-misplaced-inside-subpackages is plain
subpackages-which-are-irrelevant-for-srpm-creation.
--
You are receiving this becaus
@nim-nim Subpackages *must* be evaluated because you can put BRs with
subpackages, and those are still collected and put into the main SRPM, among
other things.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
> @nim-nim, @eclipseo: It would be deeply flawed if `rpmbuild(8)` allowed an
> invalid spec file to be used for a package build
@Conan-Kudo The spec is perfectly fine and valid, and the assertion will pass.
At the *right* time, when the parts the assertion checks against are available,
not at `
@nim-nim, @eclipseo: It would be deeply flawed if `rpmbuild(8)` allowed an
invalid spec file to be used for a package build. The `rpmbuild` tool serves as
the validator of the spec file and attempts to fail early if it looks like a
broken package spec after evaluating the macros.
--
You are re
@ignatenkobrain,
@eclipseo is trying to add a manual `%pre` to a spec to fix past packaging
mistakes, applying one of the fedora fixup guidelines. It fails because the pre
applies to a part of the spec that is not generated before `rpmbuild -bb` (not
`rpmbuild -bs`) stage.
The `rpmbuild -bs` s
> `%gopkg` should not expand to `%pre` if no package is generated by that macro.
I do not understand what you mean. `%gopkg` does not expand at SRPM build time,
that's the crux of the issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
`%gopkg` should not expand to `%pre` if no package is generated by that macro.
--
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/issues/674#issuecomment-485225235__
> Meh, I think everything needs to be correctly set during build of SRPM too.
What is your solution to our current conundrum then? go-rpm-macros can't be in
the default buildroot and rpm fails without it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email d
Meh, I think everything needs to be correctly set during build of SRPM too.
--
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/issues/674#issuecomment-485144286_
Following my issue #672:
In Golang packaging (Fedora), the -devel subpackages are computed by a Lua
macro called `gopkg`. They are handled by the `go-rpm-macros` package. This
package is a BR for all Go packages, so available when we build the RPM.
However, since it is not in the default BuildR
12 matches
Mail list logo
