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:
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
@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
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
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
`%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
`%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:
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,
(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:
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
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
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:
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
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:
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
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
> 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)
> 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
> 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
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.
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
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
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:
@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
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
@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
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
@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
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
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
@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
@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
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
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:
> 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
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
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
> 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
>
> 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
> 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
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
> 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
> 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
> 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
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
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
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
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
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
@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
If we had `%build_requires -f
@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:
@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
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
54 matches
Mail list logo
