Re: Versioning Fedora-built xdg-apps and runtimes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux