nim added a new comment to an issue you are following:
``
Basically, specifying BuildRequires manually does not scale anymore. git has been so
successful in making software projects cheap and easy, you have a forest of
inter-component build dependencies, that change quickly (blame Linus for this if you want
to blame someone. I rather like the result myself).
For a long time already, and for many software languages, it has been impossible to
identify BuildRequires manually by reading a static human-oriented INSTALL document and
translating it manually to BuildRequire lines.
At best you have some form of computer-oriented software manifest inside each version of
the source archive that tells you what the current BuildRequires are (maven-style). At
worst you need to run code inspection tools on the codebase to analyse the needs of this
codebase (go-style). Both require you have finished preparing sources so you can execute
the bit of software that reads the manifest or performs the software analysis.
It's not an autoconf-style world anymore. Software does not adapt to the state of the
system it builds on. Internet is cheap. git is cheap. vms are cheap. Open source software
is plentiful. Take my BuildRequires list and make it available, or I won't build.
Don't pretend to me you're one of that old legacy unixes where installing anything
is impossible, I don't believe you and I don't care.
Preparing the codebase for this check is basically what a packager does in `%prep`.
That's why the Java SIG wrote pm_request in the first place. To reuse the work done in
prep and avoid managing a separate "compute buildrequires" packaging process.
Golang, as a post-git computing language, pushes this to the next level. Not only you need
to run tools on the codebase, but you need to run them for pretty much every package
version bump, because the dependency set changes quickly between versions.
So you can no longer afford to run things semi manually in a separate workflow, then copy
the result to a static list, then feed it to a spec, then rebuild the again the resulting
with a static BuildRequires list in the spec (multiply by a gazillon of interdependent
software components)
It eats your packager precious time. It demotivates them. Some start replaying old
BuildRequires lists to avoid the recomputing. Your mass rebuilds start failing because of
the nest of not-needed-anymore-but-still-present BuildRequires lines in spec files. And
you have no way to detect those before mass rebuild post mortems, because the whole
BuildRequire computation happens outside the normal build process.
And, even when you find an ultra-motivated packager that will do things right every time
without QA controls, every minute he spends computing BuildRequires out-of-band, then
injecting the result in the spec file, is one minute less he has to check build logs, test
the resulting package, engage with upstream to get problems fixed.
What pm request permits is first to pull back the whole dependency computation process
within the scope and control of Fedora tooling and second to automate it away to liberate
precious packager time.
And thus make it possible to package more and better, without requiring a mass of new
packagers. And make it possible to package things, that would be too expensive in manpower
to package otherwise.
pm request is not dangerous, because everything it sources comes from Fedora repositories,
so assuming we did our reviews and QA right, is safe to use. And if a BuildRequired
package is unsafe wasting someone's time to write the BuildRequire line manually,
won't make it any safer.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7878