On Tue, Apr 30, 2019 at 10:04:55PM -0500, William Pitcock wrote:
On Tue, Apr 30, 2019 at 8:50 AM Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
> On Tue, Apr 30, 2019 at 9:47 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com>
wrote:
> >
> > On Mon, 29 Apr 2019 at 20:09, Rex Dieter <rdieter(a)gmail.com> wrote:
> > [..]
> >>
> >> The work required to fix packages affected by this disadvantage
> >> (potentially) far outweighs any advantage
> >
> >
> > Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if
in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm
dependencies autogenerator add "Requires: pkgconfig" if package has any on the
list any pkgconfig file -> rebuild all affected packages.
> > It should take ~1h for someone with proven packager priviledges.
> >
>
> Note that removing /usr/bin/pkg-config from the build environment also
> stops pkgconfig() Provides/Requires from being generated.
Indeed, synthesizing pkgconfig() entries based on the presence of .pc
files is not necessarily sufficient enough. .pc files can define
aliases using their own Provides rules. The information is best
generated by using pkgconf to dump the dependency graph.
Similarly, the requirements may as well be generated by using pkgconf
instead of trying to parse the .pc files with grep and sed itself as
the syntax is not necessarily consistent. Many of the 'hotfix'
releases in pkgconf involved mitigating problems where our parser
would get confused by unexpected data in .pc files.
Let me stop you right there: the generator we have
(/usr/lib/rpm/pkgconfigdeps.sh) uses /usr/bin/pkg-config (which is now
actually a compat interface provided by /usr/bin/pkgconf) already.
grep and sed are not involved.
Zbyszek