Nay on this one from me.
Given the generally and relatively small number of files found in buildroots
and thanks to fs caching, running 'find' in buildroot per script takes up an
irrelevant amount of time, where the KISS brp- scripts does a perfectly good
job (unless horribly implemented) of detecting the usual small amount of files
to deal with.
This RFE seems inspired from the the internal dependency generator which
implements file classification (ending up in binary rpms post build, in
contrast to what is proposed for brp- scripts in this RFE) now externalized to
foo.attr files rather than hardcoded in source.
Use of this classifiation during build time to determine which files to run the
relevant generator scripts are used for reducing the amount of times spent on
generating dependencies as each script is invoked once time per individual
relevant file.
This is really horrible design as simply making the generator scripts spit out
filename together with dependencies generated for would be able to achieve
same, with each script being run just once for whole buildroot (as with the
external dependency generator, which people might've noticed was much faster
than the internal generator which is now taking up most of the build time for
certain packages now due to how the scripts are invoked numerous times rather
than just generating all deps in a single run).
For Mandriva where we've had a ton of brp- scripts run at end of build (see
#122), the amount of time spent on is rather neglible from our experience,
which makes me lean towards this RFE as an encouragement of overengineering and
complexity that's not really necessary (unless proven otherwise).
If packagers in Fedora (I assume) have to explicitly add buildrequires in order
for brp scripts to work rather than relevant package type pulling them in
automatically or manually add commands to %check (which is really not the right
place for adding them in lack of brp- scripts, they're supposed to be run at
end of %install, ie. %__os_install_post), that's more of an issue with the
packaging itself (if libappstream-glib pulls in more dependencies than
desirable just for appstream-util which I assume has less dependencies, then
the better solution would be to simply split appstream-util out in separate
package to be pulled in automatically by rpm-build or whatever package would be
appropriate).
Mind you, I might totally misunderstand your RFE, as I share similar thoughts
on the matter as @n3npq ...
--
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/issues/308#issuecomment-324399548
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
