Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Implemented as of commit 58dcfddc376a7c97de1432f0082be0d5f01adbcd -- 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-496447889___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Closed #104. -- 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#event-2371238045___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@eclipseo My understanding of things is that you just need to have a BR
generator that supports this distinction, no need for special rpm support
```rpm
%if %{with check}
generate-foo-buildrequires --full
%else
generate-foo-buildrequires --without-tests
%endif
```
That's the nice thing of getting buildrequires generation integrated within
rpmbuild, you get all the existing spec framework for free.
--
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-475847335___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Will it be possible to condition BR generator to output only main deps without tests deps? In some case it could be useful to break a cyclic deps to not have the tests deps included. -- 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-475771193___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Haven't read this all, but it seems to fit the bill wrt. use case I tried to tackle at the mock side in the past: https://github.com/rpm-software-management/mock/issues/11 Nice to see it's becoming a popular request, finally :-) -- 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-449291600___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
`%generate_` would be my vote -- 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-435050523___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
`%generatedeps` or `%generatebuildrequires` are my votes. -- 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-434576177___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
The main problem I see is that current rpm does not like more than one -f flag, and complex packages that mix several kinds of things would probably want more than one of those. OTOH `%files` shows this is not a blocker. And the script approach, while it allows calling several commands easily, does not lend itself to splitting output by subpackage, which is what you want for non-srpm things. -- 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-434033907___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
(But if that’s too hard to do please just do the `%buildrequires` part as discussed before. We need it now. In fact we’ve been needing it for a decade at least) -- 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-434028166___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
What a wonderful idea. You’re right. *BuildRequires* are the current pain
point, but there's no reason the rest won’t want to be done after this problem
is fixed.
However I think the way rpm syntax tries to pretend rpm and srpm are symetrical
makes you miss the obvious. rpm and srpm are not symetrical. srpm-things are
package-wide and need to be evaluated at specific points of the build process.
rpm-things OTOH can all be evaluated at the end of the build process when rpm
packages are assembled, but they are (sub-)package specific.
Therefore I don't feel the script syntax model is the right one. Something like
`%files`, with a static manual list of elements, and an optional file of
computed elements, will probably work better.
So how about something like this?
```specfile
# Declarative section. For syntax symmetry
# Static BuildRequires could be migrated here over time
# Anything needed in %prep or by the macros used before prep
%sourcedeps
BuildRequires: x
BuildRequires: y
# Script section
%prep
# Another declarative section. With an optional computed list and static
declarations
%builddeps -f
BuildRequires: z
# Script section
%build
[…]
# Declarative sections for the built packages
%files -f
%doc xxx
%deps -f
Requires: moo
Obsoletes: foo < %{version}-%{release}
%files devel -f
%doc yyy
%deps devel -f
Recommends: a_compiler
```
* that makes it clear what is srpm-specific and what is (sub)-package specific
* it makes it clear when each part is evaluated
* it allows mixing static and dynamic declarations freely
* it's symetrical with `%files` and won`t feel alien to existing packagers.
* it's extensible: you don’t need to invent new script names for every
possible dep clause, you can add support for new clauses over time to the same
section
And that opens the way to more syntax cleanups in the future, like
straightening up of the headers that apply to the srpm and those who apply to
the rpm (once upon a time Build* applied to the srpm and the rest to the rpm,
but that has changed since, and the limit between those is not obvious nowadays
as long as they are not in separate sections). Or merging `%files` and `%deps`
in a new section. Or cleaning up Sources/Patches via a `%prepfiles` that
applies to the srpm. There are lots of things that could be done at some point
of the future.
Short-term, we only need to implement `%builddeps`.
--
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-434023402___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Oh, sorry I should have been more specific what I mean with "other dependencies". I don't think we need more different kind of build requires. But it may be interesting to add scripts for Provides, "normal" Requires, Conflicts, all the weak deps, well probably not obsoletes. This is currently totally speculative but I could imagine a future where we have build time scripts for those. Basically dependency generators on spec level. -- 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-433981146___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
something not too long to type would be nice however -- 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-433936369___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
I proposed somewhere above a %build_requires (with some options, too), but that would probably be too huge overlap, right? Can we operate with brackets or options? Like `%dynamic_requires -t build`? -- 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-433931854___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
How about `%buildreqs` `checksreqs` `%prepreqs` `%installreqs` scheme? Warning: I suck at naming -- 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-433919735___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Ok, I tried to sketch a POC patch and it turns out executing arbitrary scripts and breaking builds is something not too foreign to rpm. We still need a good name for the section. Unfortunately %buildrequires already is taken by the macro with the (static) buildrequires. It would be nice to have a naming scheme that would work for other types of dependencies, too. Just in case we'd like to add something like that in the future. Suggestions? -- 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-433916346___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Well, the result of %buildrequires could be added if the srpm is build side by side with the binary packages. We could add some marker if it is build stand alone. So you could know in advance that there are dynamic buildrequirements still missing. -- 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-433298639___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> I can run repoquery to check that nothing requires what I intent to retire > etc. If we generate those, we should make sure the srpms we put in the source > repo have the info in them available. I can imagine `rpmbuild -bs --try-really-hard` which would: 1) generate src.rpm the classic way 2) run %prep and %buildrequires 3) generate new src.rpm with injected requires from %buildrequires I can make support in mock for that and we can make this default in Koji, so all builds from Koji will have full set of buildrequires and you can still repoquery them. I am not afraid about Koji/Mock, but what about OBS @mlschroe ? -- 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-433249318___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> The rpmbuild side of things can probably be done quite easily. No idea about > the build system stuff. I actually like this idea and as maintainer of mock, I can promise implementation of this in Mock. -- 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-433248114___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> One thing that concerns me is that now when srpms require certain packages, > this information is visible from the source repo. I can run repoquery to > check that nothing requires what I intent to orphan etc. If we generate > those, we should make sure the srpms we put in the source repo have the info > in them available. That's pretty much what I wrote in https://github.com/rpm-software-management/rpm/issues/104#issuecomment-431577981 if you want to do this kind of thing, you need either to redefine srpms as "current srpm + result of %buildrequires" or some other format between current srpms and rpms which is "current srpm + result of %buildrequires" . And then just output this format during builds, store it in repos the usual way, query it with repoquery, etc. Since the solution proposed by @ffesti does not require any special new rpm header, as long as you output this format, I don't think the rest of the tooling needs any specific adaptation. But, that's an enhancement. It's not strictly necessary to make dynamic buildrequires work. -- 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-433054259___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
That's interesting think for policy POV, thanks. That would certainly be an issue for FESCO before allowing us to use that in Fedora. But I don't think it is necessarily a blocker for the actual implementation in mock/rpm. -- 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-433053248___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
One thing that concerns me is that now when srpms require certain packages, this information is visible from the source repo. I can run repoquery to check that nothing requires what I intent to orphan etc. If we generate those, we should make sure the srpms we put in the source repo have the info in them available. -- 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-433050948___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Well yes in theory. In practice you never have enough info to debug a problem quickly so a setup like `%prep`or `%build`where rpm echoes each executed line, and where you can insert debugging printfs as needed, is pretty much ideal. -- 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-433050497___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Isn't that for stdout/stderr separation is for? All we need is to display the one that's not used for the reqs. -- 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-433049137___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@ffesti As a packager, I'd do it that way just because having stdout taken over sucks from a debugging POW. That's one of the things I dislike most about autoprovs: no easy way to put debug statements to stdout when there is a problem (I've been known to write autodep code that echos fake "debug(anything I need to know)" provs to diagnose problems). -- 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-433047865___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Yup, something along these lines. It would be encouraged to do the part right in the %buildrequires section and use scripts that write directly to stdout but this pattern would also work. -- 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-433039439___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@ffesti So, just to be sure we understand ourselves, we could have something like: ```specfile %prep %buildrequires cat buildrequires.lst %build ``` That works for me. Nice clean simple and effective. I assume the syntax of the lines outputted in `%buildrequires` would be the same as current `BuildRequires:` lines, without the `BuildRequires:` line header? -- 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-433030417___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
OK, so: Add support a %buildrequires script that's executed after the %prep during the binary build. If it exists it is executed and its stdout read in as BuildDependencies. These are then checked. Those not found (or all of them) are printed out and written to a file and the build is terminated with a special exit code and the message: "Please install these additional build dependencies. They can be found in $BUILDROOT/__rpm_build_requires". Build systems would react with installing the new dependencies (may be caching the list somewhere) and restart the build afterwards - may be even with some short circuit param that uses the result of %prep and %buildrequires. The rpmbuild side of things can probably be done quite easily. No idea about the build system stuff. -- 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-433024163___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@praiskup
> -> we could simply print the list of BuildRequires to stdout (newline
> separated list of BRs).
>From a packager and macro writer POW a file like in %files -f is a bit simpler
>to manipulate – after a while one gets lost between the macro stdouts that are
>intended to write parts of the spec file, the ones intended to end up in
>%{echo:, the ones you want to end up in build logs, and so on. Plus taking
>over stdout prevents the use of good old echo/printf to debug problems.
But, I could live with stdout. I'd just prepare a detached file in `%prep` and
cat it in `%req`
--
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-433016835___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, October 20, 2018 2:51:03 PM CEST nim-nim wrote: > So, with a year of hindsight, I've simplified the requirements to > > 1. run `%prep` > 2. run BuildRequires computation logic (either as part of prep or in a new >`%reqs` section between prep and build) I'd still prefer the separated section; (1) it would be clear what specfile/SRPM uses the dynamic BR computation, and (b) it would make the interface much more clear -> we could simply print the list of BuildRequires to stdout (newline separated list of BRs). Also - to keep things sane - the new section shouldn't change the %_builddir (mock _should_ execute that part with read-only %_builddir ideally). > 3. install the computed BuildRequires in the build root before `%build` if >you're running in one of those (ie mock). -- 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-433002932___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@praiskup > If I remember correctly, somebody > suggested to do "fix-point" calculation (install dynamic BR in loop, till > something gets installed - but I doubt this is needed in real world). That was me and after playing with the concept for a year I agree you can live without it in the real world. A single install transaction before `%build` is sufficient. -- 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-432988614___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@ffesti I thought the same thing as you at first but you don't absolutely need the separate BuildRequires syntax. You can perfectly limit static BuildRequires to the part needed to compute additional BuildRequires before `%build` and just add any static BuildRequires needed for %build or %check to the output of this computation. (from a technical POW that's just putting those BuildRequires in an expand, and cat >> the result to the dynamic BuildRequires file) So, from a technical POW, sure the separate syntax would be nice to have, but it's not absolutely *required*. -- 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-432987623___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Well, the issue here is what is the procedure to build the package. There are two options: The one I sketched above with a two stage SRPM build. You could use BuildRequires(pre) or something similar to setup the second stage SRPM build. (You probably can replace the first stage by a pure parsing pass.) The other option is to spit out the additional requirements during the build of the binary packages by executing a %buildrequires script between %pre and %build and hope the build system is capable of installing those on the fly (or restarting the build afterwards). This seem much more fragile and dangerous as it requires root operations being triggered from a non root build. Overall the static Buildrequires are not quite the same as the Requires needed to calculate the dynamic BuildRequires and they should be kept separate. Especially for the cases where there is no script for dynamic build 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-432979163___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Of course, the SRPM format needs to be updated first; so we can store the dynamic build requires "unexpanded" there. -- 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-432973624___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> But for determining the dynamic BuildRequires (or even just running %prep) you will need additional tools. So the question is where do you get the Requires from for these. You have static `BuildRrequires` for this puprose. Those should be installed first, so the dynamic build requires can be calculated. If I remember correctly, somebody suggested to do "fix-point" calculation (install dynamic BR in loop, till something gets installed - but I doubt this is needed in real world). -- 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-432972680___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
I agree that %prep is needed to do this. But there is another thing to think about: Right now BuildRequires are the Requires of the SRPM. So the procedure is to build the SRPM and then use its Requires to set up the build root. So you do not have any Requires for building the SRPM. And indeed the SRPM can be build without any additional tools and libraries. But for determining the dynamic BuildRequires (or even just running %prep) you will need additional tools. So the question is where do you get the Requires from for these. So you probably need to do: - Build SRPM - See that it contains dynamic BuildRequieres - Rebuild SRPM with BuildRequires(pre) installed running %prep and the dynamic Buildrequires scripts - Setup the build root with the SRPM and build the binary rpms -- 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-432966176___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Anyway, to put things back into perspective, since I spent a one more year trying to progress on the subject. The constraints of a BuildRequires generator are the following: 1. you need to unpack sources 2. you need to fix those sources if they have problems so the generator gives accurate results (otherwise, GIGO) So concretely you can not run the generator before the end of some processing that does * unpack * patch * remove broken code * put files in the right place Notice something? That's pretty much the definition of `%prep`. Anyone who thinks the contrary, is just lucky enough to have upstreams that release perfect sources, that need no fixing before the BuildRequires generator is run. So to run any BuildRequires generator you need a `%prep` bis. And it better do the same thing as the current `%prep`, because computing BuildRequires on a code state, which is different from the code state fed to `%build`, is unlikely to produce happy results. (All this was not actually that obvious when I started this road, it took many refactorings and cleanups before I realized my BuildRequires computing logic was replaying `%prep` with BuildRequires computation at the end). All the solutions that pretend computing BuildRequires without executing `%prep` in rpmbuild, just redefine a `%prep`, with its associated requirements, somewhere else. At best it just duplicates needlessly the specfile `%prep`. At worst it is slightly different (which will eventually result in bugs at `%build` or `%check` stage). And it's all hidden behind abstraction layers that obfuscate it's just a `%prep` stage, nothing more and nothing less. So, with a year of hindsight, I've simplified the requirements to 1. run `%prep` 2. run BuildRequires computation logic (either as part of prep or in a new `%reqs` section between prep and build) 3. install the computed BuildRequires in the build root before `%build` if you're running in one of those (ie mock). So, it mainly needs to define how the BuildRequires compute engine must present the computed deps to the rest of the tooling. The options I see are: * generate BuildRequires lines, * talk to the buildroot manager over a socket (à la pm request) * set a rpm variable or tag (probably awful if the BR list is long or complex) * generate a list of BuildRequires using current BuildRequires syntax in a filename that has been defined somewhere in a standard tag or variable (this solution may be the easiest to manage for the rest of the stack). The moment when the rest of the tooling must parse the result is the end of `%prep`. (or the end of `%reqs` if people want to separate it from `%prep`). And *optionally*, as a further *enhancement*, because some people like to run `rpm -q` on srpms 1. either define a query mode that executes `%prep` + `%reqs` 2. or define an intermediary `rpmbuild -bx` stage that outputs something srpm-like, with the result of `%prep` + `%reqs` recorded in its headers. Or in the generated BuildRequires files included in the pseudo-srpm, with sources and spec file. Does not matter as long as you can run `rpm -q` on the result. Both of those probably want some form of `ReqRequires` to distinguish between things needed at `%prep` + `%reqs` from things needed at `%build` + `%cheks` (and I'm sure all the people here have wished at some time in the past that `%build` and `%cheks` requirements were also cleanly separated without custom ifdefing in spec files). But, all the second part is an *enhancement*. The basic need one can not avoid, only hide behind abstraction layers is: 1. run `%prep` 2. run BuildRequires logic (either as part of prep or in a new `%reqs` section between prep and build) 3. install the computed BuildRequires in the build root before `%build` if you're running in one of those (ie mock). -- 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-431577981___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> Seeing an existing example would really help to justify the additional > complexity. As I said, I don't have such an example (and hope won't have for some time). It's just the kind of things I see upstreams do. > Such problem smells like equivalent to bootstrapping distro from scratch > problem. And what I see from the recent movement out there (non-RPM world), bootstrapping is rather ignored in language stacks since if you build something once, you don't have a reason to bootstrap again. Since most Go projects do not use dynamic libraries, setting up the deps of a non-trivial project is similar to bootstraping, yes. They tried to ignore lots of things and it just moved the complexity at the project level. That's why the soonest it is all plugged in rpm where there is know-how to deal with those, the better > the "looping" would certainly go against simplicity. Anyways, no strong > disagreement here :-) As long as you're ready to add it later, I don't care much (only that I'm quite sure that if it's required we'll manage to get EL stuck on the feature-free, and pay the price in "can not be packaged for EL" later). As I've shown you don't even need to maintain a dynamic BR state to loop, just to test in the install does something -- 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-366436094___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> With git clone so easy nowadays I'm pretty sure some of the language > upstreams will bake multi-phase BR solving in their tooling sooner or later > (if not already done). Seeing an existing example would really help to justify the additional complexity. Such problem smells like equivalent to bootstrapping distro from scratch problem. And what I see from the recent movement out there (non-RPM world), bootstrapping is rather ignored in language stacks since if you build something once, you don't have a reason to bootstrap again. That said, I *don't* view automatic bulid-requires generator as something difficult to hack on, maintain, or use; the "looping" would certainly go against simplicity. Anyways, no strong disagreement here :-) -- 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-366435273___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> I'm not sure calculating "fixed point" for build requires dependency graph is > required in the first place. Having BuildRequires and then single-step > dynamic build requires would be powerful enough I think, and easier to > implement from buildsystem pov. To be honest, I don't think I need looping for Go, but I'm not sure I won't need it either (the Go dep situation is evolving fast those days as things have reached a "can't continue like before" point). The "correct" future-proof way to do it is looping (for IT definitions of future-proof, that is) > Slight benefit would be that packagers would be much less motivated to do > **very complicated magic** in build-depsolving. I'm not fearing packagers as much as upstream language ecosystems. Sure, some packagers will write their own custom BR logic but most major languages will just call upstream language tools in %buildrequires (without _ please, so it's consistent with %buildroot and other historical rpm bits) With git clone so easy nowadays I'm pretty sure some of them will bake multi-phase dep resolving in their languages sooner or later (if not already done). I'd rather not have a brand-new dynamic BR that lasts a month before they obsolete it. -- 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-366430457___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 9:57:13 AM CET nim-nim wrote: > > [snip, mock could ... ] > > - does installroot and installs BuildRequires as usually > > - runs %prep > > - runs %foo_analyzer from %build_requires > > - runs the rest of the build > [snip] > > That would work too, as long as you take into account a package may declare > several %foo_analyzer Well we could stick with %build_requires %foo_analyzer %bar_analyzer if we baked the script into SRPM _unexpanded_, and build system was responsible (through in-chroot rpm) for expanding ... user could pick how many analysers he wanted. Well, we wouldn't have to bake this into SRPM at all in the end -- but just add some "flag" mentioning that "this is SRPM which needs multi-step buildrequires resolution", so build system knows how to switch to the appropriate multistep build mode. The actual run of %build_requires would be performed from extracted specfile. > and you probably need to loop their execution with BR population till there > is no new results to handle complex cases transparently. That's an analog of > my "implicit looping". I'm not sure calculating "fixed point" for build requires dependency graph is required in the first place. Having BuildRequires and then single-step dynamic build requires would be powerful enough I think, and easier to implement from buildsystem pov. Slight benefit would be that packagers would be much less motivated to do **very complicated magic** in build-depsolving. > > this way you don't have to adjust depsolver, only the build-system. > > The main drawback being that if rpm is completely unaware of this, it > can not abort local builds with a sensible error if the local system is > missing one of the dynamic BRs If I understand you correctly, the dynamic build requires would be slightly weaker compared to the standard BuildRequires; is that a real problem? IOW, the semantics would be like `rpmbuild --nodeps` was enabled for them. In theory, rpm could reexec the %build_requires script before continuing with %build just to check that nothing is missed... but then we would have to expect that build system does the "fixpoint" calculation as mentioned above. I wouldn't be sure then that we are not stepping to far to academic field.. -- 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-366429346___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> Agreed. IMO rpm should just speficy "script" which prints build-requires to > standard output. That can/could be: %build_requires # the script content > /bin/awk ... do something or %build_requires -f > or %build_requires -s . this way you don't > have to adjust depsolver, only the build-system. The main drawback being that if rpm is completely unaware of this, it can not abort local builds with a sensible error if the local system is missing one of the dynamic BRs -- 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-366427810___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> Theoretically yes, but I don't think we have to go that far. Btw. the set of > build-requires wouldn't be "constant" for each build of particular package > and that would be big -1 from me (at least if you consider bootstrapping > scenario where everything isn't completed yet). Whatever the calculated > build-requires set would be, I wish it was constant for each build, > regardless of what's in buildroot at that time. I'm pretty sure it will be constant, if only because once you go the dynamic BR route, the initial build root is likely to be sparse with few things that can influence the build. But even if it weren't, is that's such a big deal? The set of BRs is already not constant – the only constant part is the first level explicitly declared BRs, but those can pull in different second level BRs depending on the repos state or depending on their own version. And a lot of the weird effects in Go stem from their attempt to remove second-level BRs from the picture (in a lala-lala dev world no rpm-style dependencies — no rpm dependency hell, when if fact it only moves the tricky effects to another point) -- 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-366426996___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
> Contrarian examples are trivial to devise. Consider an autoconf based > generated file that builds if (and only if) certain files are detected. None > of those BuildRequires can be automated and generated during a spec file > parse with a pipe/file redirection. That's more or less the Go system right now, computing deps is just a special compiler mode where it dumps what it will need instead of building the project (it is slowly evolving as a separate command, but still, it will continue to call Go compiler innards behind). So that depends what you call "build" if "building" means calling the compiler yes that's building, my definition of building is producing files. I don't think it needs more than one phase at present though. > Repopulating a buildroot with additional "dynamic" BuildRequires and > restarting an rpm build either needs to teach rpm how to install additional > packages as a side effect of parsing, It only needs to teach rpm to: - pass dynamic BRs requests to the buildsystem, - bomb if the BuildSystem is unable to provide them (and in case of no build system, bomb if the dynamic BRs are not already present). - continue otherwise There is not need to add BR provisioning logic to rpm itself, that has not been its role for quite a long time. >or needs to be handled by dep solvers that populate the build root (entirely >out of scope for the current rpmbuild implementation) before rpmbuild is >invoked. I think everyone would prefer the current responsibility separation where rpm does the parsing and building and the build system does the provisioning > There is currently no known way other than "works" to verify that the > BuildRequires passed to the depsolvers that populates the build system used. You're over-engineering things. Builds can fail with static BR too, a requires system has never promised builds *will* succeed, only that the material they should need is present at build time. > Only looping to test that the BuildRequires are sufficient. That's why I proposed a two-command compute-BR/populate-BR system, that makes incremental dynamic BR composition possible, and places the packager/language integrator in command of when dynamic BR population is needed, and whether it is needed once or several times (everyone will understand that the populate-BR is expensive in build time, so the packager's interest will be to batch as much compute-BRs as possible to limit populate-BRs calls) Of course you can make the looping implicit, force the packager to declare all the compute-BR engines (a project can include code in several languages) before a specific step in the spec, and then at this step loop - execution of all compute-BR - populate-BR till first step produces no dynamic BR not computed before. That's a more brute-force approach. It will possibly be simpler to use by packagers, at the expense of increased build times (because the compute-BR logic will necessarily be simpler and more brutal too) and making some use-cases like declaring the BRs needed by unit tests in %check impossible. > Hence any attempt to automate BuilRequires MUST have a persistent incremental > store from which the automagically generated BuildRequires can be retrieved > on the final build. "final" build is a murky concept when a project can include code in several languages, and %checks can include many tests which are all small build units. I'd rather have a system that either declares the end of %prep or %prep-br the final limit after which no BR resolving occurs, or no rpm-enforced limit with an explicit fetch-BR command that can occur in all spec sections that need new BRs Now as you astutely noted: 1. adding BRs is necessarily incremental (dynamic BR removal is too horrid to contemplate and all the systems I know are additive, not substractive, at worst the build commands know how to ignore stuff it doesn't need or want) 2. rpm needs to remember the result of the last compute-BR call to - abort the loop when no new BRs are produced in case of implicit looping - return a "you already asked this" error code from populate-BR if you go the explicit call route -- 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-366426484___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 7:40:53 AM CET Jeff Johnson wrote: > If -- as this RFE seems to assume -- you are going to limit the implementation > to "... (Rust, Python, golang) ..." that have alternative non-specfile means > to specify BuildRequires, then all known rpm build systems will require a > change to augment the installed files with newly discovered "dynamic" > BuildRequires. It is up to the build system whether it is going to implement this; the worst case scenario would be to ignore the new format so people won't be allowed to use the feature "because guidelines". > Repopulating a buildroot with additional "dynamic" BuildRequires and > restarting an rpm build either needs to teach rpm how to install additional > packages as a side effect of parsing, or needs to be handled by depsolvers > that populate the buildroot (entirely out of scope for the current rpmbuild > implementation) before rpmbuild is invoked. Agreed. IMO rpm should just speficy "script" which prints build-requires to standard output. That can/could be: %build_requires # the script content /bin/awk ... do something or %build_requires -f or %build_requires -s . this way you don't have to adjust depsolver, only the build-system. -- 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-366423220___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 7:18:47 AM CET Jeff Johnson wrote: > Contrarian examples are trivial to devise. Consider an autoconf based > generated file that builds if (and only if) certain files are detected. > None of those BuildRequires can be automated and generated during a spec > file parse with a pipe/file redirection. Understood, but (at least I hope) we aren't trying to find ultimate answer for all packages/languages out there. Some languages try to solve this problem by having list of build requires set upstream, e.g. python: https://packaging.python.org/specifications/declaring-build-dependencies/ We could also think of some heuristic which goes through extracted upstream release tarball, and calculating "what is needed". Packagers would still have %prep for doing `rm` for particular parts of sources which they don't want to build (which is good safety measure anyway, see java packaging practices). > The only solution (I can see) is an attempted build on a system with > "everything" installed that then repeats with the BuildRequires: > detected from the "everything" build. Theoretically yes, but I don't think we have to go that far. Btw. the set of build-requires wouldn't be "constant" for each build of particular package and that would be big -1 from me (at least if you consider bootstrapping scenario where everything isn't completed yet). Whatever the calculated build-requires set would be, I wish it was constant for each build, regardless of what's in buildroot at that time. Maybe I'm missing the point of the issue (OP to decide), but I think this has real and pretty trivial engineering solution for some languages: - distribution provides heuristic for language Foo in foo-build package - package Baz puts 'foo-build' into build requires - package Baz adds "%build_requires --script %foo_analyzer" to declare that the buildsystem should attempt to generate build requires after %prep with %foo_analyzer script - this brings new file/value in generated SRPM to let build-system know - mock finds %build_requires section in SRPM, so it - does installroot + and installs BuildRequires as usually - runs %prep - runs %foo_analyzer from %build_requires - runs the rest of the build In the stack it means: - build system needs an easy way to split build process to two parts (there's --short-circuit, but packages created with this basically aren't installable) - incompatible chnage, so build-systems need to be adjusted -- 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-366422836___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
If -- as this RFE seems to assume -- you are going to limit the implementation to "... (Rust, Python, golang) ..." that have alternative non-specfile means to specify BuildRequires, then all known rpm build systems will require a change to augment the installed files with newly discovered "dynamic" BuildRequires. Repopulating a buildroot with additional "dynamic" BuildRequires and restarting an rpm build either needs to teach rpm how to install additional packages as a side effect of parsing, or needs to be handled by depsolvers that populate the buildroot (entirely out of scope for the current rpmbuild implementation) before rpmbuild is invoked. -- 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-366421642___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
Contrarian examples are trivial to devise. Consider an autoconf based generated file that builds if (and only if) certain files are detected. None of those BuildRequires can be automated and generated during a spec file parse with a pipe/file redirection. The only solution (I can see) is an attempted build on a system with "everything" installed that then repeats with the BuildRequires: detected from the "everything" build. There is currently no known way other than "works" to verify that the BuildRequires passed to the depsolvers that populates the build system used. Only looping to test that the BuidRequires are sufficient. Hence any attempt to automate BuilRequires *MUST* have a persistent incremental store from which the automagically generated BuildRequires can be retrieved on the final build. -- 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-366420520___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
On Saturday, February 17, 2018 12:08:53 AM CET Jeff Johnson wrote: > @nim-nim: there are classes of BuilRequires: that are not known until after a > build This sounds interesting, don't you have specific example? It rather sounds like bootstrapping issue which the BuildRequires generator isn't supposed to solve. Maybe I finally see what you meant by chicken-egg problem, but this is not what the RFE is about.. > Start designing a collection/query system that can be added to existing > build systems before fiddling around with pipe/file mechanisms and spec > file syntax (the answer will be obvious if you succeed in > capturing/querying BuilRequires). I think I don't really understand what what you propose, how this querying should work? -- 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-366418607___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@nim-nim: there are classes of BuilRequires: that are not known until after a build, so continuing a spec file parse isn't close to an adequate solution, nor does the mechanism (like a pipe instead of a file) or location (like within a *.spec or a *.rpm) make any difference. There is no existing rpm based build system prepared to handle persistent incremental build file generation. Start designing a collection/query system that can be added to existing build systems before fiddling around with pipe/file mechanisms and spec file syntax (the answer will be obvious if you succeed in capturing/querying BuilRequires). -- 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-366384693___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
If we had `%build_requires -f
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@nim-nim: "... define the best dynamic BR strategy over time" is *EXACTLY* the chicken-egg problem mentioned by @ffesti. Think a bit ... -- 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-364815788___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
@ffesti You're complicating things unecessary, rpm does not distinguish between manual and dynamic provides, there's no need to distinguish between manual and dynamic BuildRequires either In a dynamic BuildRequires world, the spec still contains static BuildRequires (sufficient to pull in the build root whatever is necessary to compute the dynamic BuildRequires) and the packager executes at the end of %prep whatever command or commands are appropriate to compute those BuildRequires That allows the packager to "fix" the project state that serves as a base to the computation, to massage the command output if needed, etc All it needs is an rpm entry point that pipes a string or a string list into the BuildRequires list during %prep, for mock or whatever to read the final BuildRequires state at the end of %prep and complete the build root as needed If you want maximum flexibility you can even forget about %prep or not %prep, and do it with two spec verbs: 1. one verb that accepts piping new BuildRequires (one per line, without the BuildRequires prefix) or alternatively as arguments 2. another verb that basically kicks the build system and tells it "add to the build root all the BuildRequires not already present" and let packagers define the best dynamic BR strategy over time. Adding BRs just in time would simplify a lot of ifdefing in %build and %check for example: just request the BRs in the optional section instead of trying to sync several optional sections in different parts of the spec -- 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-364795706___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
There clearly is some chicken - egg problem here as one will likely need some tools to determine the dependencies for the build. So there needs to be a multi step process: Getting the BuildRequires that are needed to determine the dynamic Buildrequires Generating the SRPM with all the BuildRequires Get all BuildRequires. Building the Binary RPMs. This is clearly not possible with most of the existing build systems. So changing this will require changes to basically all of them. We would probably need to add something like BuildRequires(srpm) and add a new section in the spec file that can be used to create the dynamic BuildRequires. Another question is on what files this BuildDeps generator/section should operate. Obviously executing %prep before hand would be very helpful for many use cases. The next question is whether the Dependencies should be generated automatically - by scripts provided by rpm and run in the background or if packagers would need to write their own section generating the dependencies - may be by executing some rpm provided scripts. -- 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-264459206___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
