On Tue, Nov 28, 2017, at 09:37 AM, Bastien Nocera wrote:
I had a chat with Owen shortly after the Fedora 27 release, and
I'm guessing
the status hasn't changed for folks like myself that need to be able to make
changes to the lower OS layers and have them persist across reboots, correct?
I'd like to refer things like this to docs; there's
https://github.com/projectatomic/atomic-host-docs/pull/84
which unfortunately is stalled a bit, see
https://github.com/projectatomic/atomic-host-docs/issues/95
Will try to pick that back up.
I need to be able to, amongst other things:
- be able to switch kernels independently of the OS installation
This one is
https://github.com/projectatomic/rpm-ostree/issues/946
- be able to install external kernel modules for particular kernel
revisions and
have them persist across reboots
- be able to modify daemons, be it startup scripts, udev/hwdb rules, or binaries
and have them persist across reboots
We actually do support this today with `ostree admin unlock --hotfix`. I tend
to discourage people from using it because changes will be silently discarded
if you upgrade (or make any other changes via rpm-ostree).
That said we totally could support a model where we capture changes
from `sudo make install` and the like in a layer and have it re-apply on top
of everything else. A lot like combining `rpm-ostree install /path/to/local.rpm`
with `rpm-ostree ex livefs`. Would that cover what you wanted?
Can you flesh this out slightly more and we can write up an upstream issue?
For example are you using `sudo make install` or are you building local
RPMs or something else? Is jhbuild involved, etc.
Do we have any tracking bugs to collect requirements for that sort of
usage, or
is it outside the scope of Atomic Workstation?
It's completely in scope; generally rpm-ostree issues upstream are the best
place to track this. The big picture vision is that we support all types
of development/testing scenarios, the same as one would with a traditional
package manager. Because in production, one often needs the ability
to e.g. install a patched iptables RPM to add some debug printfs.
But all host system mutation runs through rpm-ostree
which means it has the opportunity to make all changes transactional,
and avoids the hysteresis of traditional package
management - we make it easy to reset back to the "gold master" state
which is always there.