> Still haven't gotten around to look this in any real detail, but here's
> another thought: why limit this to only buildrequires? One of the major
> shortcomings of the "new" dependency generator is the inability to generate
> package specific dependencies easily, and this looks like a nice general
> approach to that. So perhaps this should be %generate with an argument to
> specify which kind of dependencies are being generated (buildrequires,
> requires, provides...).
That would be tremendously useful for cases where runtime deps might need to be
generated in a package specific way. For example, a Ruby application may have a
`Gemfile` to indicate its dependencies, but it isn't built as a Ruby Gem. As a
consequence, there's no way to process those dependencies through the current
dependency generator system. A lot of Python applications also do this by
shipping `Pipfile`, `pyproject.toml`, or even just a `requirements.txt` file
for this. These files don't get installed on the system, and they generally
don't produce metadata at install time, so the only way to generate deps from
them is by reading the file and processing it at build time.
It'd be great if we could have support for that too.
--
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/593#issuecomment-437360067
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
