On Thu, 2016-04-21 at 16:55 +0200, Alexander Larsson wrote: [...] > > * What happens if we evolve the Fedora runtime during the > > development release - say we add a new package to it that we find > > we are repeatedly bundling into applications. Can we make the > > behavior for the user better than simply having xdg-apps that rely > > on the new package in the runtime die with obscure error > > messages? > The idea with xdg-app runtimes is that they define a stable ABI, so > that old apps keep working. This means you should avoid to add things > to them (as then new apps may break on older runtime versions), but > additionally you should mainly do bugfix updates and not version > bumps in the runtime. However, xdg-app doesn't enforce this any way, > and it can't in general because things like unstable nightly > snapshots of runtimes are an interesting and useful thing. Basically, > it is up to the producer of a runtime to define (and document) the > stability of a runtime and for producers of apps to pick a runtime > that has a stability guarantee that works for them. > > This is a bit problematic for fedora, as historically we've been > pretty gung-ho about version updates in the middle of a stable > release. The runtime will be smaller and more core though, so perhaps > it will see less of such updates. Without any actual data to back it up, I don't think the types of libraries that appear in the runtime actually get non-bug-fix updated during a stable release very often. What I'm mostly concerned about is the devel phase where libraries *should* be getting updated, dependencies added, and so forth. Is the user experience going to be very bad here if the apps get out of sync with the runtime, with apps refusing to start or crashing obscurely? Maybe gnome-software simply needs to check for a newer available version of a runtime when installing an application that uses a runtime. For runtimes and applications created from RPMs, we have some idea that we should be shipping the RPM database information in the xdg-app. There would also be a possibility to check that the RPMs bundled in the runtime satisfy the dependencies of the RPMs bundled in the application, but that doesn't work in the general case, and a failure could only realistically could be used to trigger for a check for a newer runtime. And then why not just do that to start with? - it's a single http roundtrip. [...] > > * How should apps generated from Fedora packages be versioned? > > Presumably we don’t want each Fedora version to be a branch in this > > case, since we want automatic updates. Are refs pointing to > > devel/testing/stable versions are something added post-build into > > the repository? > For the gnome runtime and app releases I'm using two branches. One is > "master" which gets a new build from git every day, and the other is > "stable" which gets builds of the latest released version. That way, > if you install the stable one you will automatically get updates. > > ostree doesn't currently support tags, so there is no clean way to > get a particular (old) version of an app. Technically one could make > a branch for each release, but that is a bit unclean imho (and it > explode the size of the repo lists). Do you think there should be a field in the metadata that is a version string provided at build time (not implying any comparison), so that a tool could look at a repo and show the old versions on a branch in some human readable form? Or should that be in the ostree commit message? > > * We probably will be creating some sort of bundles when we build > > apps and runtimes in Koji. (This is what my prototype does using > > the existing xdg-app ostree delta format.) What do we use for > > filenames for these bundles? The RPM nvr of the application itself > > doesn't tell the story because of the bundling of dependencies > > in the application. Is the filename just based off the hash of the > > xdg-app like ‘eog-f23-d3dafc9cf48.xdgapp’? Do we add a build- > > serial to make it clear what bundle is newer - e.g. ‘eog-f23-14- > > d3dafc9cf48.xdgapp’ ? > > Having a build serial seems useful, but that implies some kind of > permanent storage of how many builds each app has. Do we really have > that? Something could be added to the koji database, or we could even just use the koji task ID - that would be more like: eog-f23-13799291-d3dafc9cf48.xdgapp But still would allow comparison. - Owen -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
