Colin Walters 125c482b1d 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-30 14:27:55 +00:00

2.9 KiB

Raw Blame History

Raw build instructions

First, releases are available as GPG signed git tags, and most recent versions support extended validation using git-evtag.

You'll need to get the submodules too: git submodule update --init

rpm-ostree has a hard requirement on a bleeding edge version of libhif - we now consume this as a git submodule automatically.

We also require a few other libraries like librepo.

So the build process now looks like any other autotools program:

env NOCONFIGURE=1 ./autogen.sh
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc
make

At this point you can run some of the unit tests with make check. For more information on this, see CONTRIBUTING.md.

Using the Vagrant box

The easiest way to get started hacking on rpm-ostree is to use the vagrant machine. This is also the set up used for our integration tests.

One-time setup

Starting the vagrant machine is as easy as:

host$ vagrant up
host$ vagrant ssh

The VM for now uses the official centos/atomic-host box. However, because rpm-ostree is tightly coupled with other projects such as ostree and libhif, the code in HEAD may require a more recent version than available in the latest official box.

For this reason, you may want to rebase the VM onto the CentOS Atomic Continuous stream, which will contain the latest HEAD versions of these dependencies (normally within the hour). To rebase, simply do:

vm$ sudo rpm-ostree rebase centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
vm$ sudo systemctl reboot

If you need to test your code with custom ostree or libhif builds, you have no choice for now other than making your own tree (and yum repo for use by the build container). We're hoping to improve this workflow soon.

Hacking

The make vmoverlay command will automatically sync the current files to the VM, unlock the current deployment, build rpm-ostree, and install it.

If you need to test on a locked deployment with the updated rpm-ostree baked into the tree, you can use the make vmbuild command, which will install rpm-ostree into a new deployment and reboot the VM to use it.

For convenience, the make vmshell command does the same as make vmbuild but additionally places you in a shell, ready to test your changes.

Note that by default, all the commands above try to re-use the same configuration files to save speed. If you want to force a cleanup, you can use VMCLEAN=1.

Testing

The make vmcheck command performs the same task as make vmbuild, but additionally starts the integration testsuite.