Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Also FWIW, regarding the second commit dropping the pkgconfig-requires: those dependencies exist for the parent directory, not the tool itself. Obviously eg a filesystem-style package could provide those directories too, in which case the requires would indeed be wrong, but traditionally the directories come from pkgconfig package. The technically correct solution would be requiring the directory in which the .pc's are placed, but file/directory dependencies are not very fashionable these days as they introduce other issues for depsolvers. -- 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/411#issuecomment-376136591___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Closed #411. -- 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/411#event-1540623460___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
I am closing this. This is not because these two changes are the wrong thing to do. But changing the default behaviour places a burden on the distributions on deciding. This is acceptable for very clear cut cases that will allow most distribution just dropping their patches they have for changing to the new default anyway. The pure length of the discussion here is an indicator that this is bets left untouched upstream and handled by the distributions to their needs. -- 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/411#issuecomment-376134308___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
May I ask the maintainer for the update about commit or refuse this PR? (if refuse .. why?) -- 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/411#issuecomment-374447346___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> I'm sorry, are you obtuse? I know these are dynamic in Fedora. But Fedora > isn't the only RPM-based Linux distribution. My comment started with "BTW". It means in this case that this comment has nothing to do with submitted PR patches. Those patches have nothing to do with what people are doing in OpenSuse and why they are doing this that way. Is it clear now? Please focus on the topic of the PR. I think that I've already delivered enough pieces of evidence that **generally** using --print-requires-private generates to broad dependencies as long as none of the open source projects packaged using rpm are using Requires.private using --print-requires-private option. So far nothing that has been mentioned in the comments here is in contradiction with such claim. The only impact which will cause remove --print-requires-private option will be dropping few thousands of dependencies which will not break any existing build procedures described in existing specs files. -- 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/411#issuecomment-372605406___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
>This is an OpenSUSE problem that those packages provide only static libraries
>in case of those packages. In libsolv.pc libsolv.a is offered by:
> `Libs: -L${libdir} -lsolv`
I'm well aware of the error in their pc file and CMakeLists. That is something
I'm planning on correcting.
> BTW: in Fedora, those packages provide only shared libraries.
I'm sorry, are you obtuse? I _know_ these are dynamic in Fedora. But Fedora
isn't the only RPM-based Linux distribution. If you're going to have a
conversation about changing something upstream, you need to be cognizant that
there are many other Linux distributions that rely on this functionality.
I know of at least four distribution families, and two of them have literally
hundreds of derivatives between them, so it's a very wide impact that a change
will make.
--
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/411#issuecomment-372516897___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> Also, openSUSE statically links libsolv to libzypp, and libdnf statically
> links libsolv in openSUSE too. There are a number of packages that are, in
> fact, statically linked, and static library subpackages are provided if
> shared libraries are also provided.
This is an OpenSUSE problem that those packages provide only static libraries
in case of those packages. In libsolv.pc libsolv.a is offered by:
`Libs: -L${libdir} -lsolv
`
And there is no Requires.private line. Sorry to say this but your example has
nothing to do with what pkgconfigdeps.sh script does,
BTW: in Fedora, those packages provide only shared libraries.
--
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/411#issuecomment-372515752___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> Meanwhile you asked for a known case where libs.private is/was necessary: > statically linking rpm to neon was one such case. You mean line: `neon.pc.in:Libs.private: @NEON_LIBS@ ` ?? This line is not about use by neon Libs.private from other packages by about providing by neon.pc file with what kind libraries need to be linked some other binary if it needs to be linked as the static binary. This is not the case which is related to what does scripts/pkgconfigdeps.sh script. 1) in current version this script uses Requires and Requires and Requires.private 2) In all cases where rpm is used now, all distributions are trying to minimise distribution all static libraries all Libs.private and Requires.private are useless because all those distributions do not deliver those libraries. -- 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/411#issuecomment-372512341___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Also, openSUSE statically links libsolv to libzypp, and libdnf statically links libsolv in openSUSE too. There are a number of packages that are, in fact, statically linked, and static library subpackages are provided if shared libraries are also provided. -- 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/411#issuecomment-372485086___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Eliminating every static library build as well as every possible means to produce a static library using pkg-config is one way to justify the elimination of libs.private dependency extraction in rpm. Meanwhile you asked for a known case where libs.private is/was necessary: statically linking rpm to neon was one such case. -- 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/411#issuecomment-372477975___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> There are surely many dependency errors with libs.private because static
> linking is rarely attempted.
In distribution like Fedora, I'm not able to find even one case as none of the
source trees uses {Libs,Requires}.private so this issue is nor about rarity.
As you see the case which you been thinking that it may be in the collision
with what I've proposed is not something which could be used as the argument
against fixes proposed in this PR :)
If anywhere are used {Libs,Requires}.private .pc files dependencies there must
be only some custom made use cases which happen outside the area of any rpm
based distributions.
This is why I'm trying to convince to remove use --print-requires-private from
rpm vanilla source code.
--
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/411#issuecomment-372441353___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
The usage case was statically linking rpm (for which a strong case persists: see discussions in fedora-devel re splitting upgrade transactions to ensure that "the rpm stack" is functional dragging in library dependencies). At the time, the needed Kerberos gssapi linkage was _NOT_ included in *.pc files (so you are unlikely to find a deliberately not included dependency using grep). There are surely many dependency errors with libs.private because static linking is rarely attempted. -- 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/411#issuecomment-372320731___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Juste checked neon source tree: ``` [tkloczko@domek neon-0.30.2]$ grep -ir libs.private configure: # pkg-config >= 0.18 will use "Libs.private" iff necessary, ChangeLog:* neon.pc.in: Reorder Libs/Libs.private to fix static linking (Alan H). ChangeLog:* neon.pc.in: Define Libs.Private; use only NEON_PC_LIBS in Libs. NEWS:* Use Libs.private in neon.pc for newer versions of pkg-config. neon.pc.in:Libs.private: @NEON_LIBS@ configure.ac: # pkg-config >= 0.18 will use "Libs.private" iff necessary, [tkloczko@domek neon-0.30.2]$ grep -ir -- --libs | grep -i pkg configure: NE_SSL_LIBS=`$PKG_CONFIG --libs openssl` configure: NE_SSL_LIBS=`$PKG_CONFIG --libs gnutls` configure: NE_PK11_LIBS=`$PKG_CONFIG --libs pakchois` configure: NE_PXY_LIBS=`$PKG_CONFIG --libs libproxy-1.0` macros/neon.m4: $1_LIBS=`$PKG_CONFIG --libs $2` ``` So nothing in neon tree is using other libraries Libs.private. -- 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/411#issuecomment-372308722___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> The neon library used to use libs.private to hide a dependence on gssapi. I > don't know what the current state of affairs is. I don't see anything in neon source tree about checking other libraries Libs.private. Can you point where you see this? If your application is using neon API you don't need to link it with gssapi or you need those libraries only in case if your application is using gssapi as well. Nothing here needs to hidden. Again: generating dependencies basing on ,pc file Libs.private and Requires.private is not about for example library described by this .pc file but about any applications which will be using such library described in such file. Please do not mix this case with any other possible cases where .pc files are used. BTW autoconf and m4 macros. pkgconf provides pkg.m4 file with few PKG* macros. Those macros provides easy way to use pkgconfig based checks in other projects. None of those macros are doing any checks against Libs.private. In other words, any autoconf based build suit which is using pkg.m4 macros by definition does not even check/care what is in Libs.private or Requires.private .pc files. So again: I'm 100% sure that all autoconf based build suits which are using macros from pkg.m4 are clean and for those projects generating rpm packages dependencies using --print-requires-private switch is the incorrect way of generating those dependencies. -- 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/411#issuecomment-372300729___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
The neon library used to use libs.private to hide a dependence on gssapi. I don't know what the current state of affairs is. -- 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/411#issuecomment-372273651___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> You do know that not every distribution subpackages out static link
> libraries, right? Fedora does it, but plenty don't. For example, Debian
> doesn't (yes, I know Debian doesn't use RPM, but you said all Linux
> distributions).
Trust me. I'm building packages more than 25 years (Solaris old SysV and IPS
one, rpm and debs) and you can find traces of my work even in almost all rpm
based distributions (just try on RH centos "rpm --qa --changelog | grep
kloczek").
Exactly the same policy about not using static libraries is now present in
Debian based distributions for the same reason which I've already mentioned.
All those changes started more than 10 years ago after Solaris *BSD started
applying this approach.
Currently, any *-static packages are provided not to use on building packages
but because mainly some test frameworks usually executed in %check sections are
using few static libraries.
As I said IMO sooner even these few remaining cases will disappear as someone
will start fixing those test units.
Ths has no relation to the fact that at the moment NONE of the other packages
is using pkg-config dependencies listed in Libs.provate and Requires.private.
> IMO if you want to remove those private requires, then you should make them
> something like Requires: (pkgconfig(xxx) if $name-static), otherwise nack.
I don't want to remove anything. I have no idea of where did you took this.
Again: current scripts/pkgconfigdeps.sh script by use --print-requires and
--print-requires-private switches **together** causes adding cumulative static
and dynamic libraries dependencies when almost all (with only a few remaining
exceptions which IMO sooner or later will disappear as well) packages from all
currently generated packages by any distributions are using only shared
libraries.
IMO at the moment using in .pc files Libs.private and Requires.private is
pointless as so far I was not able to find even one source package which
queries those fields. If you will find such example please let me know :)
In other words: pkgconfigdeps.sh script provided by rpm is generates wrong
dependencies (way broader than it should be) using static libraries
dependencies which do not exist in any distributions.
> That said, the top three build systems for software packaged as RPM all
> prefer and will use pkg-config to find things if /usr/bin/pkg-config is
> available: CMake, Meson, Autotools
Thre is no any straight connections between using those build framework,
pkgconfigdeps.sh. script and rpm spec files (which are using autogenerated
dependencies).
If CMake, Meson, Autotools based build framework are using pkg-config command
and in spec file is implemented using those frameworks in this exact spec file
should be added "BuildRequires: pkgconfig" or similar.
Currently autogenerated by pkgconfigdeps.sh script dependencies are **not other
packages built time dependencies but packages listed in BuildRequires install
time dependencies**.
It is yet another fact related to static libraries.
Sometimes people are using statically linked binaries because non-pic code
sometimes is 15-20% faster.
Problem is that a few years ago most of the distributions started injecting
-pic to gcc options by providing in gcc parameters -spec= in which by
default is added use -pic/-pie.
Example from Fedora:
```
$ rpm --eval "%__global_compiler_flags"
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
$ cat /usr/lib/rpm/redhat/redhat-hardened-cc1
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
```
This causes that even if some package provides some static library .o files
inside ar archiives are compiled as PIC/PIE code.
Other distributions slowly follow the same path.
This last remaining reason to use statically linked binaries already have been
killed in distributions like EL7 and Fedora.
--
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/411#issuecomment-372162552___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> IMO if you want to remove those private requires, then you should make them > something like Requires: (pkgconfig(xxx) if $name-static), otherwise nack. If this is done, it should be a downstream change, as static subpackage naming convention differs across distributions. -- 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/411#issuecomment-372158857___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
IMO if you want to remove those private requires, then you should make them something like `Requires: (pkgconfig(xxx) if $name-static)`, otherwise nack. -- 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/411#issuecomment-372157882___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
> Static libraries do not exist in most of the distributions and it is not the > assumption. You do know that not every distribution subpackages out static link libraries, right? Fedora does it, but plenty don't. For example, Debian doesn't (yes, I know Debian doesn't use RPM, but you said _all_ Linux distributions). > Nevertheless, this workaround is not needed as current rpm-build package > requires pkgconfig. Please tell me you're not making a judgment like this solely on Fedora's `rpm-build` package and that everyone packages the software they build? Also, this dep generator specifically pulls it `/usr/bin/pkg-config`, the tool used to utilize these. This is no different than the case of `-config` binaries from really old libraries. It's entirely possible to install devel subpackages without `rpm-build` being present on the system, precisely so that someone can do development against them... That said, the top three build systems for software packaged as RPM all prefer and will use `pkg-config` to find things if `/usr/bin/pkg-config` is available: * CMake * Meson * Autotools And things fail in very strange ways when it's not there. Somehow you missed the huge change where most things now _do_ ship and use pc files via `pkg-config` to build software. And prior to the dep generator automatically adding it, it was policy in most distributions to add it for _every_ package that ships `pkg-config` files to both BR and Req `/usr/bin/pkg-config`, so that dep generation works and that people can use it properly. -- 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/411#issuecomment-372157679___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Static libraries do not exist in most of the distributions and it is not the assumption. In this exact context adding today in .pc files Requires.private and Libs.private is pointless. More than 14 years ago in first Solaris 10 distribution release have been no longer shipped libc and libm. Currently, Solaris 11 has no at all static libraries with only a few exceptions like static flex library. In Fedora static libraries are no longer widely used except few scenarios: 1. link static binaries used by some test suites 2. provide static libraries which have no stable ABI interface like binutils libraries The main reason why static linking is no longer widely used are security reasons. In case of any CVEs in libraries used in some statically linked binaries, it is necessary to rebuild all those binaries In case libraries as DSO is only necessary to rebuild package which provides affected binary. The second reason why static binaries should not be used are ABI changes. Using static linking makes those changes way harder to maintain. Nevertheless, in all Linux, *BSD, Solaris and other systems distributions use Requires.private should be used only if someone is thinking that library A provided by package B might be used to produce statically linked binaries using the library A. Effectively this is no longer possible and if something is linking with the library A it means in ~99.99% dynamic linking. Generate pkgconfig dependences for dynamic linking using static linking scenario produces redundant dependencies. Adding automatically pkgconfig to package Requires is the second part of redundant dependencies generated by current scripts/pkgconfigdeps.sh script. ``` The second change is just dumb, because the pkgconfig implementation is necessary for even using it, and ensures that build scripts that implicitly expect pkgconfig to be available for querying the file will work. ``` This is chicken and egg problem and the result of the assumption that if package A has "Provide: pkgconfig(foo)" it does not mean that this will be used in another package spec file *always* in form of "BuildRequires: pkgconfig(foo)". This is not the typical case because many packages still do not use pkgconfig on checking for example foo library. The simple solution of this wrings solution is to add "BuildRequires: pkgconfig" if "BuuildRequires: pkgconfig(foo)" is used. Nevertheless, this workaround *is not needed* as current rpm-build package requires pkgconfig. In other words on building any package from spec file which has "BuildRequires: pkgconfig(foo)" using rpmbuild command accessibility to pkg-conf command us guaranteed by rpm-build package Requires. As long as install rpmbuild will cause instantly install pkgconfig spreading across many other packages "Requires: pkgconfig" is 100% redundant. Many packages provides .pc files and they are not used on building other packages. -- 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/411#issuecomment-372154841___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
Conan-Kudo requested changes on this pull request. NAK. These changes are unnecessarily harmful. The first change makes the assumption that static link libraries don't exist in a distribution, and that they would be considered functionally useless. On top of it, without the private requires, certain linking situations actually break with more poorly designed dynamic link libraries (e.g. libraries that aren't properly opaque in their interfaces and leak in API requirements from dependencies). The second change is just dumb, because the pkgconfig implementation is necessary for even using it, and ensures that build scripts that implicitly expect pkgconfig to be available for querying the file will work. -- 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/411#pullrequestreview-102893496___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)
1) remove --print-requires-private from $pkconfig parameters
It generates list of Requires when static linking is used:
$ pkg-config --help | grep -A1 -- --print-requires-private
--print-requires-private print required dependency frameworks for
static
linking to stdout
By using this option generated list Requires is flooded static linking
requirements
when all distributions now are trying to avoid even build and provide any
possible
static libraries.
2) Remove add pkgconfig to list of generated Requires is at least one .p… …
…c file was found.
Provide .pc file by any package does not mean that it will be used.
Usually .pc files are used on building other packages.
By this redundant Requires in Fedora almost 750 packages packages requires
pkgconfig.
$ dnf -qC repoquery --whatrequires pkgconfig --qf="%{name}"| wc -l
748
pkgconfig should be only in Requires if for example in autoconf .m4 macros is
used
pkg-config (to provide the list of libs or cflags). In any other case pkgconfig
or pkg-config
should be used only in BuildRequires.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/411
-- Commit Summary --
* remove --print-requires-private frpm $pkconfig parameters
* Remove add pkgconfig to list of generated Requires is at least one .pc file
was found.
-- File Changes --
M scripts/pkgconfigdeps.sh (4)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/411.patch
https://github.com/rpm-software-management/rpm/pull/411.diff
--
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/411
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
