On Thursday, October 25, 2018 11:23:58 AM CEST Florian Festi wrote:
> There are two options:
> [..second option..] This seem much more fragile and dangerous as it
> requires root operations being triggered from a non root build.
1. You **wouldn't** trigger root actions (the fact that pm_request plugin
does this is only a serious blocker bug which means that we can not
ever use that in production), you'd only generate list of
BuildRequires. From security POV, it is equivalent to specify static
BuildRequires.
2. Well, it is as fragile as the first option where you need to run
something like %prepforprep before %prep. And then "restart" the
build. Or rely on the build system that it does a good thing.
I can see that option 1 would be slightly more optimal from "build system
POV", because you wouldn't necessarily install what you don't have to for
that specific build stage; but it would much less optimal for package
maintainers - because they'd have to think about the two stages, and
perhaps duplicate the %prep section.
So yes, the other thing is that we could make the BuildRequires more optimal,
like to have BuildRequires(prep), BuildRequires(danamic_buildrequires),
BuildRequires(check), etc. But this seems to be orthogonal "optimization"
RFE to this PR. And IMO the good-old-static-BuildRequires can still stay
equivalent to the *.src.rpm Requires.
--
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/104#issuecomment-432996888
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
