125c482b1d
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
7 lines
175 B
Plaintext
7 lines
175 B
Plaintext
[submodule "libglnx"]
|
|
path = libglnx
|
|
url = https://git.gnome.org/browse/libglnx
|
|
[submodule "libhif"]
|
|
path = libhif
|
|
url = https://github.com/rpm-software-management/libhif
|