GNOME Bugzilla – Bug 751188
remote ADD_IF_NOT_EXISTS with sysroot doesn't use sysroot
Last modified: 2015-07-16 16:55:06 UTC
In https://github.com/rhinstaller/anaconda/commit/438e19b8fe0f9f8d87a1a003f634d455973c87e1 I tried to support trees containing remotes. Except it doesn't work because while the sysroot API to add a remote takes a sysroot argument, we don't actually use it to read the remote configs - we always read from /etc.
Could this be addressed with something like OstreeRepo * ostree_repo_new_for_sysroot (GFile *repo_path, GFile *sysroot_path) And then have ostree_repo_is_system() take sysroot_path into account?
I messed around with this a little today and I think I have the libostree changes correct, but I got hamstrung by a bunch of CLI tests that broke. The problem is the "ostree remote add" command only takes a --repo argument and therefore has to assume the sysroot is always "/". Would you agree this command needs its own --sysroot option so it can figure out if it's dealing with a system repo?
Adding a sysroot to that command makes sense to me indeed.
This is getting a little messier than I'd hoped, but I think it might still be worth correcting. There's a couple places in ostree-repo.c where we construct the system-wide remote config path like so: SYSCONFDIR "/ostree/remotes.d" I think this is wrong. It's constructing the path according to OSTree's install prefix at compile time, not according to a runtime-specified system root. We need to be constructing the path more like: SYSTEM_ROOT "/" RELATIVE_SYSCONFDIR "/ostree/remotes.d" Where RELATIVE_SYSCONFDIR is a relative path set at compile time, like "etc". I don't think this can be reliably derived from the autoconf $(sysconfdir) variable though; I think we actually need a separate configure switch that defaults to "etc". --with-relative-sysconfdir or some better name. Does this seem sane or can you think of another way?
We can prepend the sysroot to the absolute path, no? I don't mind calling it RELATIVE_ internally but the end result seems to be the same - we'd have to add an intermediate '/'. In the end I think the real assumption we're making here is that the ostree inside the *target* is using --sysconfdir=/etc and not something like GoboLinux paths. And I'm fine with that assumption, things like GoboLinux aren't valuable enough to support.
In my case I'm building ostree to a prefix like /home/mbarnes/local for testing, with sysconfdir ending up /home/mbarnes/local/etc. If I run a test script from, say, /home/mbarnes/tmp, then prepending sysroot to sysconfdir produces some crazy path like /home/mbarnes/tmp/sysroot/home/mbarnes/local/etc/ostree/remotes.d/ I thought maybe we could get a relative $sysconfdir by slicing off $prefix if it matches, or maybe this is too much of a corner case to worry about?
Ah, I hadn't considered the developer case for prefix. Yeah, just slicing off $prefix makes sense to me then.
(In reply to Colin Walters from comment #3) > Adding a sysroot to that command makes sense to me indeed. Instead of piling on more command-line options for rare use cases, what do you think about supporting an OSTREE_SYSROOT environment variable? I can't think of any other use for the option beyond our installed tests at the moment, and the environment variable could be a nice little cleanup for some of the tests so we're not repeating --sysroot=sysroot ad nauseum.
No strong opinion, I'm OK with environment if you prefer. As a general rule it'd be nice if the commandline exposed most of what the API does, but for this specifc case, no strong opinion. To avoid duplication in the tests though I've been using bash functions in some places.
Got a solution that I think is fairly clean. https://github.com/GNOME/ostree/pull/125 Chose to go with the OSTREE_SYSROOT mechanism for installed tests, but we can still add --sysroot options to commands later if real-world use cases crop up.
Merged the PR. Commit sequence ends here: https://git.gnome.org/browse/ostree/commit/?id=df0cae437556e0e2c7e6b0c10e9750520d0c34f2