On Fri, Oct 10, 2014, at 07:52 AM, Alexander Larsson wrote: > For instance, one could have a > common repostory with files that have filenames based on (say) the > sha1 hash of the content, and then each app could hardlink from > those. Or one could have completely separate trees for each app which > are only hardlinked when we do an incremental update and keep the old > version.
This is precisely what OSTree is (but sha256 of course instead of sha1). Last time I talked to some other people who were looking at using OSTree for apps, I went back and forth on it. Having apps potentially share data with the host OS is nice, and better having apps share data with each other. (Say I'm an app author and I have 2+ apps with a common library between them). Although for apps you really don't want to allow them to ship e.g. setuid binaries. An app framework using OSTree as a data format would need to disallow that. And for that matter restrict to uid 0,0, mode 0755/0655. Interesting questions arise too as to SELinux labeling. You can't hardlink unless those are identical. And probably the OS should be in control over the labeling. Which might imply doing the commit on the client side - apps could just come as zip files or something, and they get committed then. See also https://bugzilla.gnome.org/show_bug.cgi?id=721799 - it has a few useful links. Android and iOS both have proprietary delta algorithms that have evolved over time - app authors upload zips, the server side calculates a diff based on that in a way that'll be understood by the client. _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
