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
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
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
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:
> 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
>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
> 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
> 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
> 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
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
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
> 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
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:
> 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
> 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
> 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
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.
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,
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
19 matches
Mail list logo
