I'd simply leave the file associations out of this style of dep generation
entirely, it'd be for the cases where the file associations don't make sense
which is quite a common case actually. The %generate-script could take the
subpackage as an optional argument, similarly to other spec sections.
The script execution should be refactored to use common code with doScript(),
this is duplicating a large part of it (which is ok for PoC of course). Not
sure if templates make sense here, but then again why not: the information
provided there (name, version etc) are commonly needed in generators too.
As for the src.rpm generation: I guess it should only fail to create src.rpm in
case %generate_buildrequires script itself fails, due to eg missing external
tools needed to extract the data, (such tools should be static buildrequires).
I guess it should also generate those dynamic buildrequires even in the case
where just src.rpm is being generated. Would be a fairly big change of course
since currently src.rpm creation runs no scripts, but if it worked that way
build systems would require less changes. Hmm, but then src.rpm creation might
need to honor static buildrequires again...
--
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-439370966
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
