Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop libnet-config in v2.0 #118

Open
robert-scheck opened this issue Apr 9, 2021 · 1 comment
Open

Drop libnet-config in v2.0 #118

robert-scheck opened this issue Apr 9, 2021 · 1 comment

Comments

@robert-scheck
Copy link

robert-scheck commented Apr 9, 2021

As of writing, libnet-config gets always populated with libdir, even it's a standard path, e.g. libdir=/usr/lib or libdir=/usr/lib64. While this doesn't seem to be an issue, it practically leads to downstream (RPM) package conflicts for multilib architectures, where x86_64 and i686 packages are installed, because /usr/bin/libnet-config is accidentially different in these packages (example: https://src.fedoraproject.org/rpms/libnet/pull-request/2).

Thus the kind request is to only populate libdir in libnet-config, if libdir is not one of the default paths (that's something, that ./configure should be aware of).

@troglobit
Copy link
Collaborator

Patches to fix this are of course welcome. However, the recommended way today is using pkg-config. This is also stated at the top of libnet-config:

#   Kept for compatibility with existing projects.  For new
#   projects, or those looking to upgrade, we recommend the
#   new pkg-config framework, libnet.pc.  See the README.md
#   for details on how to use it.

If there turns out to be no interest from the community to fix this, my recommendation is to drop libnet-config (in favor of pkg-config) in the next major release.

@troglobit troglobit changed the title libnet-config's is always populated with libdir, even for standard path Drop libnet-config in v2.0 May 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants