"build_clean.sh" is used to generate a distribution tarball. The tarball
contains pregenerated man pages with default values for paths, which in
turn depend on the configure options when creating the tarball.
Previously, the man page would have paths like "usr/local/etc/NetworkManager/...",
which doesn't seem the best choice for a default man page.
Explicitly set the installation paths.
Also, --disable-dependency-tracking in this mode. It may speed up the
build.
We configurably use --enable-gtk-doc/--disable-gtk-doc, but
we always require --enable-introspection (due to --enable-vala).
Add the missing build requirement to the "xsltproc" binary, which is in
libxslt package.
When we create a source tarball, documentation and other generated files
are disted. Those files depend on the configure options when creating
the tarball. For example, the generated man pages contain the compile time
configurable default values.
For that reason, it is generally better to regenerate the documentation when
building NetworkManager. However, let's set explict configure options to
have a more reproducible way to generate the tarball.
When doing a release, you should not just call `make dist`. Instead, the
proper way of creating an official source tarball is:
$ ./contrib/fedora/rpm/build_clean.sh --srpm
Since commit "c920909 contrib/rpm: put translations in
NetworkManager-libnm and NetworkManager-glib packages", both
subpackages install the same translation files without a direct
dependency between the two packages. Thus, if a user tries
to update only one of the two subpackages, it will fail
during the installation due to conflicting files.
Fix that by having the subpackages conflict (per version).
This way, the conflict is detected before starting the
installation.
https://bugzilla.redhat.com/show_bug.cgi?id=1406454
(cherry picked from commit b85b8ed6fa)
The ppp package split was introduced during 1.5.3 development. Thus,
we obsolete packages < 1:1.5.3.
Also, add conditionals around ppp-devel build-requirement.
- `make dist` requires --enable-gtk-doc --enable-introspection --with-libnm-glib
- --enable-gtk-doc requires --enable-introspection
- --with-nmcli requires either --enable-introspection or pregenerated
settings-docs.c files from the dist tarball. It does not require
--enable-gtk-doc.
There is a bit of a problem in that --enable-introspection requires
now xsltproc. However, gobject-introspection does itself not depend
on xsltproc. So, more correct might be a special --enable-doc argument,
that combines --enable-introspection --with-xsltproc. Anyway, that
seems to make it more complicated then it already is so just implicitly
(and surprisingly?) require xsltproc with --enable-introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=775003
# rpm -qf /usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service
NetworkManager-1.5.2-16352.e0c50a9703.fc24.x86_64
# rpm -qf /usr/lib/systemd/system/network-online.target.wants
file /usr/lib/systemd/system/network-online.target.wants is not owned by any package
One can install the libraries without NetworkManager. Thus, the
translations should be there.
Doing this increases the package size of the libraries significantly.
For a user who only has libnm without NetworkManager installed, this
is acceptable, because the whole point of the change is to ensure such
a user also gets translations.
For a user who requires libnm and libnm-glib packages, this
unfortunately increases the additional package size as the translations
are now present twice.
What would be better is if NetworkManager-libnm would only contain
translations for libnm/NetworkManager, and NetworkManager-glib only
translations for libnm-util/libnm-glib.
Back this out. It breaks i686 build unnecessarily now and also is
something that proabably that should run on distcheck and not package
build.
This reverts commit cf678811b5.
This allows to get rid of the dhclient requirement of NetworkManager
package and moves the package dependency to the new sub package
NetworkManager-config-dhcp-dhclient.
For the moment, I think dhclient should still be the default choice for
regular users due to dhclient providing better better previledge separation
of network facing code. A user who knows that he's doing, can now however
remove dhclient while keeping NetworkManager.
https://bugzilla.redhat.com/show_bug.cgi?id=1204226
