Okay, the conclusion here is pretty simple: we need more places and better ways
to run tests, and those ways should be designed to prevent abuse. Some checks
want to run before %install and should be allowed to do so, others would prefer
the actual packaged content etc.
I don't have the
> Rpm is not just the handful of packages in Fedora dist-git. We could
> "fix" (unbreak would be a better word) the handful of packages under our
> control, but nothing else.
Can we have `%check_before_install` and `%check_after_files`? Obviously with
better names :) And leave the current
I disagree with the specific proposal, because currently, running `%check`
after `%install` allows me to not bother with pollution of the `buildroot`
directory, e.g. with some temporary files needed to execute the test suite.
However, I like @ffesti proposal to run the `%check` even later in
> This could be seen as a feature: Allowing %check to examine the generated
> packages
Even better if %check can assert certain attributes (e.g. provides/requires)
etc. are present :+1:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
> However it is currently the best (least worst?) place to do that. Any other
> solution we've been experimenting for the past 2 years is unstable, does not
> support multiple architectures, and suffers from usability issues.
Ouch. If `%check` is the least worst place to run tests it's a little
I wonder if moving %check to a later time instead of running it earlier does
the trick. If we first package the files and run %check afterwards it cannot
influence the package contents but still has access to the buildroot.
Yes, this comes at the price of failing the build after doing all of the
> Testing actually installed stuff can only happen from an actual installation
> of that stuff, and inside rpmbuild is not really the place to do that.
However it is currently the best (least worst?) place to do that. Any other
solution we've been experimenting for the past 2 years is unstable,
> There are many good use cases for doing %check on the content of %install.
>
> Your suggestion is to do a fake install in %build and check that, but that 1.
> won't test the actually installed stuff, 2. make me copypaste possibly lots
> of code (not all %install sections are just
> Would it make sense to change `%check` as the PR here does, and at the same
> time also add a `%check_buildroot` or something that's the equivalent of the
> current `%check` and runs after `%install`?
IMHO, no. Rpm is not just the handful of packages in Fedora dist-git. It's also
suse and
Would it make sense to change `%check` as the PR here does, and at the same
time also add a `%check_buildroot` or something that's the equivalent of the
current `%check` and runs after `%install`? This would make it possible to both
have a check section that is appropriate for `make check`,
Just please "If it ain't broke, don't fix 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/pull/1618#issuecomment-814813292___
> Autotools are still heavily used, but they should not define standards for
> everything else.
RPM's behavior is pretty much defined by Autotools, as much as we don't like
it. This is one of those things I'd love to put into the RPMv6 bucket to fix...
:(
--
You are receiving this because
It doent matter what is using and how.
Changing order of the `check` and `%insytall` does not fixes or improves
anything and may cause **only** problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Autotools are still heavily used, but they should not define standards for
everything else.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Unfortunately, I would have to side here with everyone else. Even the DNF stack
stuff goes to great effort to use stuff installed in the buildroot in `%check`.
> Quotation needed. Who uses autotools these days anyway?
I think you mean "Citation needed", but still, Autotools is still actively
> Most packages execute their %check in the build directory, following the
> spirit of autotools "make check" target.
Quotation needed. Who uses autotools these days anyway?
Many many packages go to a big effort to test files from the %buildroot.
This change would significantly break
At the moment fedora `%pytes` ant `%ox` are udsing paths in %{builroot} and in
many cases there is no other way to perform `%check` than using `%{builroot}`
tree
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This will seriously complicate my life as a maintainer. There are many good use
cases for doing %check on the content of %install.
Your suggestion is to do a fake install in %build and check that, but that 1.
won't test the actually installed stuff, 2. make me copy a possibly lots of
code (not
I understand your sentiment but you are asking to change thousands of packages
with no deprecation period. This is not a cool way to introduce backwards
incompatible changes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This just means we'll run tests in %install :/
--
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/pull/1618#issuecomment-814768049___
I realize this is a somewhat controversial change of course.
The inspiration comes from discussions on Fedora devel list surrounding the new
behavior of strict buildroot content checking (commit
c1ca2e35025698328edcefa8dedee866d2ea0596 and
1110c280639b66c89da19a0f831af28845591997) which
21 matches
Mail list logo
