On Wed, 2016-04-20 at 21:24 -0400, Owen Taylor wrote: > We've been working on the idea that we should have a way to take > Fedora RPMs and > convert them into xdg-app runtimes and applications; by doing this > inside of Koji > we would be able to pretty transparently provide a set of xdg-apps > for many > existing applications in Fedora. > > (https://fedoraproject.org/wiki/Workstation/BuildingXdgApps tries to > work out > possible details.) > > I have an initial prototype of this working with a branch of Koji > (https://pagure.io/fork/otaylor/koji/commits/xdg-app, still rough), > and that > raised some questions to me about around versioning: > > * How should the fedora runtime be versioned? Is each Fedora release > (23,24,25) > a separate branch in the repository? (I'm not entirely sure if the > "branch" > of the runtime the same as "runtime-version" that is part of > the xdg-app app metadata?) The branch should be "24", etc. "branch" and "runtime-version" do indeed refer to the same kind of thing (one is the branch to build for and the other is the branch to use for the runtime it depends on). This discrepancy in terminology is a bit unfortunate, and i think we should make it use "version" instead of "branch". > * 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. At the end of the day it depends on the goal of the fedora runtime. If we want it to mainly be a vehicle for running xdg-apps created from existing fedora rpms, which we're in full control off, then having the runtime be more "slushy" is an advantage to us, but if we want third party developers to do release binaries that rely on the fedora runtimes, then we can't break backwards compat in them at all, and even adding stuff is risky. > * 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). > * 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? -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx