After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755938 - [review] cleanup NetworkManager-devel package in contrib/fedora/rpm [th/nm-devel-rpm-bgo755938]
[review] cleanup NetworkManager-devel package in contrib/fedora/rpm [th/nm-de...
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-10-01 13:26 UTC by Thomas Haller
Modified: 2015-10-23 10:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Thomas Haller 2015-10-01 13:26:46 UTC 
(this is an upstream BZ, because we are talking about the spec-file in contrib/fedora/rpm). Though this being relevant for Fedora/RHEL users, it doesn't mean that the content of contrib/fedora/rpm gets to Fedora any time soon).


There is a package NetworkManager-devel.
It mostly contains files that are relevant to libnm-glib only.
We should do something about it.
Comment 1 Thomas Haller 2015-10-01 13:28:41 UTC 
First attempt at th/nm-devel-rpm-bgo755938

(there is still a bug in it with the "Provides")
Comment 2 Lubomir Rintel 2015-10-06 15:58:39 UTC 
Pushed a fixup; verified to work.

LGTM
Comment 3 Thomas Haller 2015-10-09 21:26:51 UTC 
Some rationale...



NetworkManager-devel contains development-headers that are useful ~without~ libnm-glib. But still, the content of the package are header files that are part of libnm-glib (i.e. it contains files like /usr/include/NetworkManager/NetworkManager.h from libnm-glib's include directory).

Since libnm-glib is legacy, we would need a NetworkManger-devel package, that is based on the new libnm library (thus having instead files like /usr/include/libnm/nm-dbus-interface.h).


But we cannot put the new libnm header files into the existing NetworkManager-devel package. Otherwise we can never drop the legacy headers. IOW we don't want a NetworkManager-devel package, that contains both legacy and new parts.



We would need a new NM-devel package based on libnm and a separate legacy package based on libnm-glib.
Alternatively (what this BZ does), let's just merge the glib-free part into the NM devel packages. After all, these are only development packages and only needed for building. I think it is acceptable for a (hypothetical) QT application to have a BuildRequires: libnm-devel
Comment 4 Dan Williams 2015-10-22 22:06:38 UTC 
Yeah, OK...  They could also just copy the file into their local source tree; licensing doesn't really matter (though check with your lawyer :) because the entire file is simply defines, flags, and enums; there is no code.  That likely falls under the "phone book" argument for non-copyrightability.