https://bugzilla.redhat.com/show_bug.cgi?id=819951 Colin Walters <walters@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(walters@xxxxxxxxx | |m) | --- Comment #7 from Colin Walters <walters@xxxxxxxxxx> --- (In reply to comment #6) > That just got approved; let me experiment with ostree before I commit to > reviewing it. Question: the deal-breaker with Nix is the use of a new > top-level directory (/nix); presumably ostree doesn't have such a directory > path baked into it at compile time? (it's probably fine with the FPC if such > path is specified at runtime). Well...it is hardcoded in some places (namely ostree-switch-root.c which gets called from dracut), but it's also a command-line option (--ostree-dir) for some utilities. I'm willing to discuss the name/location of the directory, but following the Nix ticket, /var/lib strikes me as worse because it gives the impression that the data is managed/controlled by the "host" distribution, which isn't the case. While it's possible to manipulate /ostree from the host (and this is what I currently do), the real intention is that you boot into it. It's not like ostree is "just any old package". If it helps, I don't need to actually make /ostree from the RPM - I expect admins to do it by running "ostadmin init". Also, if ostree really gets rejected because of this, I'll be very sad. I spend a year of my life designing a system that allows fully atomic upgrades, and the response is bikeshedding over the name of a directory... Ultimately, where I'd like to go is that the /ostree type toplevel directory *is* standardized. Ideally we'd have FHS-like guidelines for the content of /ostree, like /ostree/etc and /ostree/var, so multiple independent codebases could use it. Maybe it gets named /system or /os or something. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review