[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OSTree <3 Anaconda

On Fri, Mar 21, 2014 at 3:07 PM, Brian C. Lane <bcl redhat com> wrote:
You need to skip this if flags.flags.dirInstall is True, directory install disables the storage code and probably also won't work with OSTree.

Right, OSTree is oriented towards bootable trees, it wants to write bootloader configuration.  Now you *can* easily just use the raw:

"ostree --repo=/path/to/repo checkout fedora-atomic/rawhide/x86_64/buildmaster/base/core /path/to/checkout".

But I can't think of a real use case for that offhand in the Anaconda context anyways.  It is useful to do inside a running system to get a tree suitable for "systemd-nspawn" though.

I'll evaluate the code here more carefully to be sure we aren't breaking dirInstall.

Why move this here instead of leaving it above writeBootLoader?

For OSTreePayload, at the moment I need to do some postprocessing of the bootloader configuration.  Theoretically I could land the changes in the RPM set to make that unnecessary, but it's hard to do without breaking things.

From what I can see of the other Payload subclasses in Anaconda, they are insensitive to whether or not the bootloader is installed by the time postInstall() is invoked.

I can break out a separate patch with this rationale to just swap the order, or I can introduce a new postBootloaderInstall() method on Payload.  Any preference?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]