Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 energy, or the cycles, to take on this now so I'm reverting the related %exclude changes (#1621) and postponing this mess to some future date. Thanks everybody for the civilized feedback and ideas :+1: I'll throw one more idea as a food for thought: what if we had some testing script slot that is designed to interact with something external that is capable of installing packages like mock - kinda like %generate_buildrequires is. The case is obviously very different, but I think there could be some interesting opportunities in this direction. -- 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-815531970___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 %check intact. And then on the Packaging Guidelines level set which one, and when, the section should be used. It will not break 3rd party packages. And it will not break any Fedora package. They will "just" violate the guidelines. And we can slowly request edits over time. -- 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-815080153___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 the process for two reasons: 1) It would actually allow to run the test suite in the `buildroot`. This would also provide very good place for running the test suite at least in the context of rubygem- packages. 2) I would know much earlier, that I have some (un)packaged files I need to take care prior spending time figuring out issues with the test suite. Someone could admit, that the test suite ensures the `buildroot` content is correct, but that is not true. -- 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-814945167___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814928299___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 sorry state of affairs, in this day and age. OTOH, simplicity is a virtue. In Finland we have this proverb "works like the train toilet" meaning something so simple and crude it can barely fail at all. "A hook to run a shell script"... :sweat_smile: It *is* broken though, just in a different manner. Now, this PR would likely be only half the story (the stick), and the other half would probably have to be the carrot: We don't want to break the *intended* use of `%check` which is running the in-source tests, but maybe we could add a separate slot (akin to autotools `installcheck`) that by definition runs after `%install` but protects the buildroot one way or the other. One possibility could be automatically copying the buildroot content to some arbitrary location and diverting $RPM_BUILD_ROOT to that directory. Or it could be after finishing the package build, but that has other issues in turn. Also note that we already have a mechanism to allow inspecting generated packages: `%_build_pkgcheck`. Another notoriously undocumented feature... -- 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-814928475___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 work and even have the - now deemed broken - packages on disk already. Otoh failing %check should be rare and requires most of the expensive parts of the build process anyway. -- 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-814914005___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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, does not support multiple architectures, and suffers from usability issues. -- 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-814882229___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 %make_install!!) and keep it with > only slight changes in two places. It's not that I'm opposed to testing the actually installed content, the issue is that the pre-packaging phase is the wrong place to do that because it can (and as we've seen, does) affect what is being packaged. Which is not okay at all, I'm sure everybody can agree with *that* point. Also, it does not actually test the installed stuff because it's in this arbitrary empty root at arbitrary path which is nothing like the environment where the code will actually execute and may require extra content to run at all (the very Python example that lead us to this). It's also not that autotools is somehow good example to follow, it's just that "%check" was quite clearly inspired by autotools "make check", but only run at the wrong time. Which is why we have a multiple (interlinked) problems, which wont go away by themselves. 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. -- 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-814876239___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 other distros, and local non-distributable packages, and existing tutorials, and packit, and rpms from the last 20 years. We could "fix" (unbreak would be a better word) the handful of packages under our control, but nothing else. -- 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-814822076___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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`, and also make it possible to check what gets installed. Even that may be too invasive, or at least requires a provenpackager to drive the work and do mass changes in all of the spec files. For instance, we have packaging guidelines in Fedora that mandate the use of desktop-file-validate and appstream-util validate-relax to check the files that got installed in the buildroot, which affects pretty much all GUI apps. This certainly needs someone to go and mass update all of the affected spec files if %check ends up being changed. -- 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-814815875___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 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-814813355___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814810509___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814807951___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 heavily used with even new projects using it every day. The Autotools 2.71 upgrade itself is proof of how pervasive Autotools actually is still. -- 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-814804491___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
> 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 backwards compatibility. If you want, maybe add a `%check_preinstall` step that can be executed in a different phase. -- 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-814798621___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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:
https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814782686___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 all %install sections are just %make_install!!!) and keep it with only slight changes in two places. That will be a spec file from hell. Please don't do this. -- 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-81450___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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: https://github.com/rpm-software-management/rpm/pull/1618#issuecomment-814777199___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %check script use-case by executing it before %install (#1618)
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 revealed cases where %check is run on buildroot content, introducing artifacts which then need to be %excluded. Because the current slot of %check technically allows and even seems to suggest that, saying "but you shouldn't do that" doesn't cut it. Having %check alter packaged content seems a total no-no though. Eliminating the possibility of misuse is by far the most effective medicine for such matters. And yes some of this further rationale belongs to the commit message, I'll update it later. -- 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-814756549___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
