On 6/9/20 3:01 PM, Nicolas Mailhot via devel wrote:
Le mardi 09 juin 2020 à 14:56 +0200, Nicolas Mailhot a écrit :
Le mardi 09 juin 2020 à 14:35 +0200, Vít Ondruch a écrit :
The proposal was to optionally disable test. When somebody asked
why,
the answer was bootstrapping. But we know how to handle
bootstrapping.
So shouldn't somebody spend time changing the test conditionals to
bootstrapping conditionals, because that seems to be the use case?
One use case is bootstrapping. Another is just getting things to
build
till you have the time to investigate if a new test failure is an
actual problem or upstream being careless as usual. There are
probably
other use cases out there
Another fun case: someone broke the dep of a component used in unit
tests. Fixing the component requires rebuilding the dep. Except, the
dep uses the component itself in its own unit tests…
There are boundless possibilities for fun and profit there (well
profit, not so sure actually)
Another common one for me is rapid development in the spec file.
Overall, bootstrapping is definitely a common reason for disabling
tests, but it's not the only one.
Using bootstrapping conditional for non-bootstrapping purposes would be
even more confusing than the status quo.
Therefore people will want to create macros that disable tests. I think
we should follow the example of the bootstrapping macro, and recommend
one macro that disables tests.
Tomas
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
