https://bugzilla.redhat.com/show_bug.cgi?id=819951 --- Comment #9 from Michel Alexandre Salim <michel+fdr@xxxxxxxxxxxx> --- (In reply to comment #7) > (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. > The FPC might be happier if all occurrences of /ostree can be overridden, but then again, it's hard to know without asking them directly. > 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. > I agree > 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... Same story with Nix :/ . Nix's tool actually allows the store location to be configurable at compile time (though I've not tested it with anything but the default); the problem with using anything but /nix is that (as I suspect will be the case with /ostree) one loses the ability to use pre-compiled archives. It will be nice if OSTree comes by default compiled with a silly FHS-compliant default, but users can override this in a configuration file parsed at runtime. Similar to how Richard Hughes had to clobber the defaults for zif not to read/write the yum database, but provide instructions on how to re-enable it. > > 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. That would be great. Do you want to ask for clarification on the packaging list before we go further? We can go ahead quietly too but that might cause a furor later on. -- 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