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 subs
> 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 d
> 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
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.
R
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 inf
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 t
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#issue
@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 "deb
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
@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 cu
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
@ascherer pushed 1 commit.
27409eb Add short rationale for shortcut '--scm=SCM'.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/564/files/824ee78bafe094f73dbded3416a760b60177a3c4..27409eb3f8a943e3e2909
@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 par
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 separa
Okay so I do see some real-world uses for specifying temporary scm from the
cli, such as not wanting backups by default but needing to rediff, so you might
want to specify "gendiff" on an occasion. Or not wanting the overhead of git or
other real scm for regular builds but wanting to use git for
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 pl
@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
@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 %chec
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
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#i
> 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 c
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 th
23 matches
Mail list logo
