rpm-ostree/.gitmodules

[submodule "libglnx"]
	path = libglnx
	url = https://git.gnome.org/browse/libglnx
[submodule "libhif"]
	path = libdnf
	url = https://github.com/rpm-software-management/libhif
Start using libglnx The high level goal is to deprecate libgsystem. I was trying to share code between ostree/rpm-ostree, but it was too painful to commit to forver frozen ABI for new utility APIs. The git submodule approach will much more easily allow breaking API/ABI, and iterate on APIs until they either land in GLib or not. Note that libglnx will not use GFile*, so a full port to it will involve also not using that. Thus, it will be necessarily incremental; in the meantime we'll link to both libgsystem and libglnx. 2015-02-15 21:56:14 +03:00			`[submodule "libglnx"]`
			`path = libglnx`
			`url = https://git.gnome.org/browse/libglnx`
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to always build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is designed for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon 2016-06-29 04:33:02 +03:00			`[submodule "libhif"]`
Update for libhif -> libdnf Still not many PRs outstanding, so it's a good time to take this plunge. Mostly automated via `sed`. Closes: #416 Approved by: Conan-Kudo 2016-08-03 21:30:17 +03:00			`path = libdnf`
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to always build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is designed for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon 2016-06-29 04:33:02 +03:00			`url = https://github.com/rpm-software-management/libhif`